Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. How Long Will Programmers Be So Well-Paid?

How Long Will Programmers Be So Well-Paid?

Scheduled Pinned Locked Moved The Lounge
phpcomquestion
75 Posts 18 Posters 1 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • E Espen Harlinn

    Good points - but it's often hard to initially figure out which one you've got on your hands during an interview - that may take several months.

    Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

    L Offline
    L Offline
    Lost User
    wrote on last edited by
    #25

    I just recently had my share of interviews. Let's look at it from the other perspective. Becoming a code monkey is the last thing I would want and during the interview I try to find out what they are looking for. When they just keep asking questions about rules, best practices or standards, then they probably want a code monkey. Code monkeys do not need to know why they are doing something. They just have to know the rules and use them to do what they are told. Things usually get interesting for me when they start to ask questions which require understanding, not mindless devotion to rules and standards.

    E 1 Reply Last reply
    0
    • L Lost User

      I just recently had my share of interviews. Let's look at it from the other perspective. Becoming a code monkey is the last thing I would want and during the interview I try to find out what they are looking for. When they just keep asking questions about rules, best practices or standards, then they probably want a code monkey. Code monkeys do not need to know why they are doing something. They just have to know the rules and use them to do what they are told. Things usually get interesting for me when they start to ask questions which require understanding, not mindless devotion to rules and standards.

      E Offline
      E Offline
      Espen Harlinn
      wrote on last edited by
      #26

      CDP1802 wrote:

      during the interview I try to find out what they are looking for

      Sometimes they only have a vague idea about what that really is.

      CDP1802 wrote:

      Code monkeys do not need to know why they are doing something. They just have to know the rules and use them to do what they are told.

      Now, that is a recipe for disaster - and far too common. When you're about to instruct the worlds most efficient idiot - which I think aptly describes a computer - it certainly helps that you know the why of things. If you don't understand it, how can you model and implement it?

      Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

      L 1 Reply Last reply
      0
      • E Espen Harlinn

        CDP1802 wrote:

        during the interview I try to find out what they are looking for

        Sometimes they only have a vague idea about what that really is.

        CDP1802 wrote:

        Code monkeys do not need to know why they are doing something. They just have to know the rules and use them to do what they are told.

        Now, that is a recipe for disaster - and far too common. When you're about to instruct the worlds most efficient idiot - which I think aptly describes a computer - it certainly helps that you know the why of things. If you don't understand it, how can you model and implement it?

        Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #27

        I already had that dubious pleasure and do not wish to repeat it. But that's what all that talk about 'standards' is all about. The developers are just better secretaries to do the typing. What they are supposed to type is dictated by the 'standards' and enforced by style checking tools. Understanding is not required. It's even unwanted, since it makes the people ask awkward questions instead of being 'productive'. And you can probably guess what happens when such a team runs into problems. They can't even start to deal with them, because they went through all the motions and rituals in the 'standardized' way which magically should eliminate any problems beforehand.

        E 1 Reply Last reply
        0
        • L Lost User

          I already had that dubious pleasure and do not wish to repeat it. But that's what all that talk about 'standards' is all about. The developers are just better secretaries to do the typing. What they are supposed to type is dictated by the 'standards' and enforced by style checking tools. Understanding is not required. It's even unwanted, since it makes the people ask awkward questions instead of being 'productive'. And you can probably guess what happens when such a team runs into problems. They can't even start to deal with them, because they went through all the motions and rituals in the 'standardized' way which magically should eliminate any problems beforehand.

          E Offline
          E Offline
          Espen Harlinn
          wrote on last edited by
          #28

          CDP1802 wrote:

          Understanding is not required. It's even unwanted, since it makes the people ask awkward questions instead of being 'productive'.

          I think I can sympathize with this :laugh: It's usually best to just leave them to it (and perhaps run for the hills). Awkward questions should be on the table as early as possible, but that might not be practical because we just landed the deal, sales is happy, management is happy - please don't ruin the mood. Good developers are really, really hard to find - and defining what actually makes a developer good is pretty hard too, it's just that some of the biggest companies in the industry has worked very hard to sell the concept of outsourcing/offshoring - which is based on a fundamental untruth about architecture and systems development: You can just hire a head.

          CDP1802 wrote:

          dictated by the 'standards'

          Seems you are talking about the kind of coders that can, and perhaps should, be replaced by code generators.

          CDP1802 wrote:

          when such a team runs into problems

          Oh, you mean blame shifting ;)

          Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

          L 1 Reply Last reply
          0
          • E Espen Harlinn

            CDP1802 wrote:

            Understanding is not required. It's even unwanted, since it makes the people ask awkward questions instead of being 'productive'.

            I think I can sympathize with this :laugh: It's usually best to just leave them to it (and perhaps run for the hills). Awkward questions should be on the table as early as possible, but that might not be practical because we just landed the deal, sales is happy, management is happy - please don't ruin the mood. Good developers are really, really hard to find - and defining what actually makes a developer good is pretty hard too, it's just that some of the biggest companies in the industry has worked very hard to sell the concept of outsourcing/offshoring - which is based on a fundamental untruth about architecture and systems development: You can just hire a head.

            CDP1802 wrote:

            dictated by the 'standards'

            Seems you are talking about the kind of coders that can, and perhaps should, be replaced by code generators.

            CDP1802 wrote:

            when such a team runs into problems

            Oh, you mean blame shifting ;)

            Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

            L Offline
            L Offline
            Lost User
            wrote on last edited by
            #29

            Espen Harlinn wrote:

            Oh, you mean blame shifting ;)

            That's also a standard. You are supposed to do it as you are told and if it works the lead will take all the credit for his brilliant planning. When it fails, you are immediatly under suspicion of having violated the unfailing standards and should expect the inquisition. In case you get off the inquisition's hook, you still are guilty because you suddently are expected to think for yourself and should have foreseen the problem.

            E 1 Reply Last reply
            0
            • L Lost User

              Espen Harlinn wrote:

              Oh, you mean blame shifting ;)

              That's also a standard. You are supposed to do it as you are told and if it works the lead will take all the credit for his brilliant planning. When it fails, you are immediatly under suspicion of having violated the unfailing standards and should expect the inquisition. In case you get off the inquisition's hook, you still are guilty because you suddently are expected to think for yourself and should have foreseen the problem.

              E Offline
              E Offline
              Espen Harlinn
              wrote on last edited by
              #30

              I'll freely admit that on a number of occasions I've gone ahead and actually trusted a few people in the workplace - and looking back, I can't remember that anything good ever came out of it. Lessons learned: 1. Do things in writing - if it isn't written, it might as well never have happened. 2. If you're going to do something extraordinary, will it be worth the effort? If somebody really has f**ked up - make sure that it's well documented, that the initial effort is shot to **ll and that there is absolutely nothing worth saving - in other words make sure you get the freedom, time and funding to do things the "Right Way™". 3. Never assume that people around you understand what you are doing, and remeber that the original team will, if given the chance, stab you in the back. Logic seems to be that it wasn't their fault things didn't work out - somehow it was you fault, and besides you are making them look bad. 4. Make sure the project manager understands that his role is to facilitate your work, make sure the other team members understands their roles. Write down a plan, develop an architecture and make sure that the stakeholders agree that this is what they want/need. This is were standardized procedures has more than one point in their favor. This is the dark side of software development: Everybody wants to have their say; whether they know what they are talking about or not - and people are at their most dangerous when they don't.

              CDP1802 wrote:

              expect the inquisition

              Always expect them to come knocking, and with a few procedures in place, it can even turn out to be a good thing.

              Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

              L R 2 Replies Last reply
              0
              • E Espen Harlinn

                I'll freely admit that on a number of occasions I've gone ahead and actually trusted a few people in the workplace - and looking back, I can't remember that anything good ever came out of it. Lessons learned: 1. Do things in writing - if it isn't written, it might as well never have happened. 2. If you're going to do something extraordinary, will it be worth the effort? If somebody really has f**ked up - make sure that it's well documented, that the initial effort is shot to **ll and that there is absolutely nothing worth saving - in other words make sure you get the freedom, time and funding to do things the "Right Way™". 3. Never assume that people around you understand what you are doing, and remeber that the original team will, if given the chance, stab you in the back. Logic seems to be that it wasn't their fault things didn't work out - somehow it was you fault, and besides you are making them look bad. 4. Make sure the project manager understands that his role is to facilitate your work, make sure the other team members understands their roles. Write down a plan, develop an architecture and make sure that the stakeholders agree that this is what they want/need. This is were standardized procedures has more than one point in their favor. This is the dark side of software development: Everybody wants to have their say; whether they know what they are talking about or not - and people are at their most dangerous when they don't.

                CDP1802 wrote:

                expect the inquisition

                Always expect them to come knocking, and with a few procedures in place, it can even turn out to be a good thing.

                Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                L Offline
                L Offline
                Lost User
                wrote on last edited by
                #31

                Espen Harlinn wrote:

                1. Do things in writing - if it isn't written, it might as well never have happened.

                Now, you are just the sort of troublemaker as they considered me to be. Can't you just do as you are told and leave the thinking to those who know everything far better than you do? :)

                Espen Harlinn wrote:

                2. If you're going to do something extraordinary, will it be worth the effort? If somebody really has f**ked up - make sure that it's well documented, that the initial effort is shot to **ll and that there is absolutely nothing worth saving - in other words make sure you get the freedom, time and funding to do things the "Right Way™".

                They will interpret that as an effort to disrupt the team and call you a selfish prima donna.

                Espen Harlinn wrote:

                3. Never assume that people around you understand what you are doing, and remeber that the original team will, if given the chance, stab you in the back. Logic seems to be that it wasn't their fault things didn't work out - somehow it was you fault, and besides you are making them look bad.

                We were the original team, most of us misused as dumb code monkeys with two lights of wisdom overseeing the whole thing. It's hard not to look bad under those conditions.

                Espen Harlinn wrote:

                4. Make sure the project manager understands that his role is to facilitate your work, make sure the other team members understands their roles. Write down a plan, develop an architecture and make sure that the stakeholders agree that this is what they want/need. This is were standardized procedures has more than one point in their favor.

                Yes, both our lights of wisdom were great at that. At least they were good at sitting in meetings, writing all kinds of documents for anybody but us and otherwise telling us to do what we are assigned. Follow the 'standards', that's all you have to know. My way to deal with it: Ask for more specifications, get sent away with some hand waving and some talk about the 'standards'. Protest loudly and predict issues that may come to bite us later, thus earning the title of troublemaker. Then I shut off the brain and followed their 'standards' to the letter. Often enough the predicted trouble happened, the inquisition found no deviation from the 'standards' an

                E 1 Reply Last reply
                0
                • L Lost User

                  Espen Harlinn wrote:

                  1. Do things in writing - if it isn't written, it might as well never have happened.

                  Now, you are just the sort of troublemaker as they considered me to be. Can't you just do as you are told and leave the thinking to those who know everything far better than you do? :)

                  Espen Harlinn wrote:

                  2. If you're going to do something extraordinary, will it be worth the effort? If somebody really has f**ked up - make sure that it's well documented, that the initial effort is shot to **ll and that there is absolutely nothing worth saving - in other words make sure you get the freedom, time and funding to do things the "Right Way™".

                  They will interpret that as an effort to disrupt the team and call you a selfish prima donna.

                  Espen Harlinn wrote:

                  3. Never assume that people around you understand what you are doing, and remeber that the original team will, if given the chance, stab you in the back. Logic seems to be that it wasn't their fault things didn't work out - somehow it was you fault, and besides you are making them look bad.

                  We were the original team, most of us misused as dumb code monkeys with two lights of wisdom overseeing the whole thing. It's hard not to look bad under those conditions.

                  Espen Harlinn wrote:

                  4. Make sure the project manager understands that his role is to facilitate your work, make sure the other team members understands their roles. Write down a plan, develop an architecture and make sure that the stakeholders agree that this is what they want/need. This is were standardized procedures has more than one point in their favor.

                  Yes, both our lights of wisdom were great at that. At least they were good at sitting in meetings, writing all kinds of documents for anybody but us and otherwise telling us to do what we are assigned. Follow the 'standards', that's all you have to know. My way to deal with it: Ask for more specifications, get sent away with some hand waving and some talk about the 'standards'. Protest loudly and predict issues that may come to bite us later, thus earning the title of troublemaker. Then I shut off the brain and followed their 'standards' to the letter. Often enough the predicted trouble happened, the inquisition found no deviation from the 'standards' an

                  E Offline
                  E Offline
                  Espen Harlinn
                  wrote on last edited by
                  #32

                  CDP1802 wrote:

                  those who know everything far better than you do?

                  I think I'll quote Bjarne on this one: People who think they know everything really annoy those of us who know we don't It can hit both ways though, and most people really aren't all that interested. Developing good software is hard, and most people want "easy".

                  CDP1802 wrote:

                  They will interpret that as an effort to disrupt the team and call you a selfish prima donna.

                  If you can, make sure you are not part of "the team". If they want to fail, be all means, let them do so without your help.

                  CDP1802 wrote:

                  It's hard not to look bad under those conditions.

                  As you mentioned, sooner or later, inquisition comes knocking - if it's later, they are probably looking for blood - and your previously "awkward" questions may just be what they are looking for. Depending on the scenario, you could even do it the "Right Way™" on your own time - if the your company needs it bad enough, it'll be worth your while. Just make sure that this is not about revenge - so be careful to make sure that you get across that you did it with the companys best interest in mind - and that you gave the initial effort your best shot - something that will require a wee bit of documentation, and a certain level of presentation skills.

                  CDP1802 wrote:

                  they were good at sitting in meetings, writing all kinds of documents for anybody but us

                  That works for a while, but in the long run management will usually notice - it may take some time though.

                  Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                  L 1 Reply Last reply
                  0
                  • RaviBeeR RaviBee

                    "But why has the supply of good engineers remained so strained?  We're talking about work that can, in principle, be performed by anyone anywhere with a half-decent computer and a decent Internet connection." R-i-i-i-ght. :) /ravi

                    My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

                    N Offline
                    N Offline
                    Nish Nishant
                    wrote on last edited by
                    #33

                    Says it all, doesn't it? :-)

                    Regards, Nish


                    My technology blog: voidnish.wordpress.com

                    RaviBeeR 1 Reply Last reply
                    0
                    • E Espen Harlinn

                      Nish Sivakumar wrote:

                      hard to hire a good developer

                      What makes a developer a good developer?

                      Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                      N Offline
                      N Offline
                      Nish Nishant
                      wrote on last edited by
                      #34

                      Espen Harlinn wrote:

                      What makes a developer a good developer?

                      From the hiring company's perspective, a good dev is one that meets their expectations and requirements. It's not a one-shoe fits all situation here.

                      Regards, Nish


                      My technology blog: voidnish.wordpress.com

                      E 1 Reply Last reply
                      0
                      • B BillWoodruff

                        Hi Nish, I have lived in Chiang Mai over eleven years (in two installments, separated by five years back in the U.S.). The merit of that TechCrunch article is really "undermined" for me by the author's ridiculous statements about Chiang Mai, based on a visit of a few days: "... I’ve spend the last couple of days chilling out in Chiang Mai, northern Thailand, a city where you could live like royalty and save money while making merely half of Google’s average developer salary." The author is correct about the possible cost-of-living you can have here, depending on your relative frugality of life-style, being a fraction of what the cost of living (in a "non-poverty" lifestyle) in any great American, or European, city, or Singapore, or Hong Kong, or Taipei, etc., would be. Where the author is absolutely wrong is in his later assumption that cost-of-living is the primary driving factor in expat migration to Chiang Mai(there are many other factors, and the author shows no evidence he has any statistical basis for his statements about expat demography): "... has tempted thousands of expats who now live here" The author then goes on to form a hypothesis from his short stay in Chiang Mai: "... And their presence [he's speaking of expats in Chiang Mai] has sparked a possible explanation for this apparent paradox." The "paradox" which the author claims is a causal factor of what he perceives as a "skewed" distribution of skilled programmers, not just in Thailand, but in other countries: is absurd; a violation of at least two of the logical principles of inference. Another absurdity in the article is where the author mentions "Chiang Mai" along with "Bangalore," as if there were a "parallel:" "Instead you’ll advance to the point at which you’re reasonably happy with your paycheck, which studies indicate is about $70,000/year in America. (But much less in Chiang Mai or Bangalore.)" Chiang Mai, and Thailand, is an "absolute zero" in software development compared to India: to Bangalore; or Hyderabad; or Mumbai. There are very few expat programmers here. Only two companies of small size that I know of in Chiang Mai, where the owners are expats, and employees, in general, Thai. There may be out-sourcing "sweatshops" here in Thailand I don't know of, where crap-work is being performed: but, since average Thai mastery of English is so poor, compared to India, you can be sure there is no out-sourcing on-line voice-chat support industry here that can be compared to India, or other

                        N Offline
                        N Offline
                        Nish Nishant
                        wrote on last edited by
                        #35

                        Thanks Bill, I didn't think the article would be entirely accurate. I was specifically interested in how it's hard to hire devs these days as I've personally experienced just that in the past 4-5 years. Great post there though!

                        Regards, Nish


                        My technology blog: voidnish.wordpress.com

                        1 Reply Last reply
                        0
                        • N Nish Nishant

                          Says it all, doesn't it? :-)

                          Regards, Nish


                          My technology blog: voidnish.wordpress.com

                          RaviBeeR Offline
                          RaviBeeR Offline
                          RaviBee
                          wrote on last edited by
                          #36

                          I found the author's comments so off-putting, I actually took the trouble to respond at TechCrunch.  First time I've ever commented on a blog/article outside CP! /ravi

                          My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

                          1 Reply Last reply
                          0
                          • E Espen Harlinn

                            CDP1802 wrote:

                            those who know everything far better than you do?

                            I think I'll quote Bjarne on this one: People who think they know everything really annoy those of us who know we don't It can hit both ways though, and most people really aren't all that interested. Developing good software is hard, and most people want "easy".

                            CDP1802 wrote:

                            They will interpret that as an effort to disrupt the team and call you a selfish prima donna.

                            If you can, make sure you are not part of "the team". If they want to fail, be all means, let them do so without your help.

                            CDP1802 wrote:

                            It's hard not to look bad under those conditions.

                            As you mentioned, sooner or later, inquisition comes knocking - if it's later, they are probably looking for blood - and your previously "awkward" questions may just be what they are looking for. Depending on the scenario, you could even do it the "Right Way™" on your own time - if the your company needs it bad enough, it'll be worth your while. Just make sure that this is not about revenge - so be careful to make sure that you get across that you did it with the companys best interest in mind - and that you gave the initial effort your best shot - something that will require a wee bit of documentation, and a certain level of presentation skills.

                            CDP1802 wrote:

                            they were good at sitting in meetings, writing all kinds of documents for anybody but us

                            That works for a while, but in the long run management will usually notice - it may take some time though.

                            Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                            L Offline
                            L Offline
                            Lost User
                            wrote on last edited by
                            #37

                            Espen Harlinn wrote:

                            Developing good software is hard, and most people want "easy".

                            Much worse. They want it to work perfectly, even if they asked for some miracles. And they want to have it yesterday, for free if possible. They want it easy? A good way would be to use the team's experience and listen when somebody wants more information or sees a problem. That's what the scrum meeting is for, and not some kind of morning prayer which is treated as a ritual where everybody lies to the others about how happy he is.

                            E 1 Reply Last reply
                            0
                            • N Nish Nishant

                              Espen Harlinn wrote:

                              What makes a developer a good developer?

                              From the hiring company's perspective, a good dev is one that meets their expectations and requirements. It's not a one-shoe fits all situation here.

                              Regards, Nish


                              My technology blog: voidnish.wordpress.com

                              E Offline
                              E Offline
                              Espen Harlinn
                              wrote on last edited by
                              #38

                              Nish Sivakumar wrote:

                              It's not a one-shoe fits all situation here

                              No, definitely not, but I feel it's an increasingly important question - even if it's impossible to provide a good answer. The skills we have differs wildly - and they are mostly aquired after leaving university, or whatever educational institution we've attended - and they are pretty hard to measure. We also, as a group, tend to get access to far more critical information than most people realize - which have aspects that's worth exploring.

                              Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                              1 Reply Last reply
                              0
                              • L Lost User

                                Espen Harlinn wrote:

                                Developing good software is hard, and most people want "easy".

                                Much worse. They want it to work perfectly, even if they asked for some miracles. And they want to have it yesterday, for free if possible. They want it easy? A good way would be to use the team's experience and listen when somebody wants more information or sees a problem. That's what the scrum meeting is for, and not some kind of morning prayer which is treated as a ritual where everybody lies to the others about how happy he is.

                                E Offline
                                E Offline
                                Espen Harlinn
                                wrote on last edited by
                                #39

                                CDP1802 wrote:

                                That's what the scrum meeting is for

                                I'm not sure scrum, or any other agile methodology, can be taught - it's what you may get after a significant period of time in a healthy workplace environment. The most fundamental ingreedient of any agile methodology is trust - and if that's not in place, it's just a futile exercise.

                                CDP1802 wrote:

                                morning prayer which is treated as a ritual where everybody lies to the others about how happy he is.

                                Not a happy situation - the morning meating is for raising and clarifying issues, determining actions and delegating resposibility - on a minor level. If you have major issues, they belong in another setting - perhaps a full project meeting involving all the stakeholders. If this isn't feasible, you're not doing scrum - just some bastardization intended to prove you're an agile organization. If the customers can't be brought into this, you - as an organization - really have a fundamental trust problem which in time will manifest itself in terms of a significant amount of trouble meeting expectations and requirements.

                                Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                                L 1 Reply Last reply
                                0
                                • E Espen Harlinn

                                  CDP1802 wrote:

                                  That's what the scrum meeting is for

                                  I'm not sure scrum, or any other agile methodology, can be taught - it's what you may get after a significant period of time in a healthy workplace environment. The most fundamental ingreedient of any agile methodology is trust - and if that's not in place, it's just a futile exercise.

                                  CDP1802 wrote:

                                  morning prayer which is treated as a ritual where everybody lies to the others about how happy he is.

                                  Not a happy situation - the morning meating is for raising and clarifying issues, determining actions and delegating resposibility - on a minor level. If you have major issues, they belong in another setting - perhaps a full project meeting involving all the stakeholders. If this isn't feasible, you're not doing scrum - just some bastardization intended to prove you're an agile organization. If the customers can't be brought into this, you - as an organization - really have a fundamental trust problem which in time will manifest itself in terms of a significant amount of trouble meeting expectations and requirements.

                                  Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                                  L Offline
                                  L Offline
                                  Lost User
                                  wrote on last edited by
                                  #40

                                  I always called it a cargo cult. Blindly imitating some methodology without any understanding, degrading every part to a hollow ritual and expecting success to arrive by magic. And if its not successful, then that's obviously the doing of the unbelievers. SaR. Software as Religion.

                                  E 1 Reply Last reply
                                  0
                                  • L Lost User

                                    I always called it a cargo cult. Blindly imitating some methodology without any understanding, degrading every part to a hollow ritual and expecting success to arrive by magic. And if its not successful, then that's obviously the doing of the unbelievers. SaR. Software as Religion.

                                    E Offline
                                    E Offline
                                    Espen Harlinn
                                    wrote on last edited by
                                    #41

                                    CDP1802 wrote:

                                    Software as Religion

                                    Yes, we're seeing too much of that these days - and "Software Evangelist" has become a "respected" profession.

                                    Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                                    L 1 Reply Last reply
                                    0
                                    • E Espen Harlinn

                                      CDP1802 wrote:

                                      Software as Religion

                                      Yes, we're seeing too much of that these days - and "Software Evangelist" has become a "respected" profession.

                                      Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                                      L Offline
                                      L Offline
                                      Lost User
                                      wrote on last edited by
                                      #42

                                      Too bad. If any religious figure ever fit to me, then it would be the apostle Thomas. I always ask questions.

                                      E 1 Reply Last reply
                                      0
                                      • L Lost User

                                        Too bad. If any religious figure ever fit to me, then it would be the apostle Thomas. I always ask questions.

                                        E Offline
                                        E Offline
                                        Espen Harlinn
                                        wrote on last edited by
                                        #43

                                        I'm off to a dinner party - t'was an interesting exchange - hope getting some of it off your chest helps, at least I've often found that it helps ...

                                        Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                                        L 1 Reply Last reply
                                        0
                                        • E Espen Harlinn

                                          I'm off to a dinner party - t'was an interesting exchange - hope getting some of it off your chest helps, at least I've often found that it helps ...

                                          Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra

                                          L Offline
                                          L Offline
                                          Lost User
                                          wrote on last edited by
                                          #44

                                          Then I wish you a nice evening!

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups