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. Are developers losing their independence?

Are developers losing their independence?

Scheduled Pinned Locked Moved The Lounge
designcollaborationquestion
30 Posts 23 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.
  • S SeattleC

    It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?

    F Offline
    F Offline
    Fran Porretto
    wrote on last edited by
    #21

    Your experience is not unique, but the cloud has a silver lining: Managers are unlearning the most pernicious of these practices, under the lash of experience.

    The disease took its first form with the Capability Maturity Model (CMM), which, in essence, told managers that they could measure, and therefore control, the engineering "process." It was a lie from the very first, but it seduced an awful lot of "spreadsheet pilots" (my personal derogation for managers who think the complexities and sophistications of any engineering undertaking can be meaningfully measured or reproduced) into thinking they could guarantee something that God Himself has made un-guarantee-able: the ultimate functionality, overall cost, and time-to-completion of an R&D project.

    Matters became really grave with ISO-9000, which purports to codify how engineering should be done. In point of fact, the only thing about engineering that can even be described was summed up in the old "waterfall" description of a project -- and that description is notional rather than intensive. But the ISO-9000 enthusiasts (once again, managers with an unshakable conviction in the precise manageability of absolutely everything, even if it's never been done before, nor anything like it) were adamant. In this, they had backing from a number of large institutions, most notably the federal government, which made the ultimate cauterizing of the wound that much more painful.

    But the universe has its laws, and it grants no exemptions from them. One of those laws is that no one can nail down all three vertices of the development triangle:

    • If you rigidly specify functionality and cost of development, the time to completion will be unknown.
    • If you rigidly specify functionality and time to completion, the cost of development will be unknown.
    • If you rigidly specify cost of development and time to completion, you have no idea what the ultimate product will do!

    It doesn't matter what your "process" is, or how you've documented and explained it, or what rewards (or punishments) you've promised for following (or not following) it. Managers learned this by imposing CMM and ISO-9000 on us, and reaping the whirlwind.

    The best part of this is that the great majority of those managers thought their new management technique would make them look like aces in front of their customers, so, in the fas

    S B 2 Replies Last reply
    0
    • S SeattleC

      I've worked at small companies too. It has come as a surprise to me when managers behaved as though the devs were simply coding monkeys, and decisions about directions needed to be kept away from them.

      F Offline
      F Offline
      Fabio Franco
      wrote on last edited by
      #22

      I've experienced that also (only once though) and saw the project head to failure because I wasn't given the liberty to implement the solution my way, which I knew it would work.

      "To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson

      1 Reply Last reply
      0
      • S SeattleC

        It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?

        T Offline
        T Offline
        TestShoot
        wrote on last edited by
        #23

        http://www.forbes.com/sites/venkateshrao/2011/12/05/the-rise-of-developeronomics/[^] Basically it says we are all nerds that don't know how important we are so acquire our talent and treat us like crap, we like it that way. Battered wife syndrome. There is a HORRIBLE gap in qualified tech leads these days. I just took over this process and found out that PM's don't know anything other than their projects (and they don't know them all that well) are the most important thing in the world, and web development is like using MS Word... it is too dorky and demeaning but they could easily do our jobs.

        *--==[::tSc::]==--* TestShoot.com Film Supplies TBB aka P90X (my day job)

        M 1 Reply Last reply
        0
        • S SeattleC

          It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?

          C Offline
          C Offline
          cpkilekofp
          wrote on last edited by
          #24

          Member 2941392 wrote:

          can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago?

          Ten or fifteen years ago the same problem existed; in some organizations today, it doesn't exist. It's worst in organizations where the manager is a former developer, but it occurs everywhere. You just got lucky in your early experiences.

          1 Reply Last reply
          0
          • S SeattleC

            It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?

            I Offline
            I Offline
            I explore code
            wrote on last edited by
            #25

            surprise me! :) I have been in both kinds of ships. 4 years ago, the company/project i was in, had a manager who was technically good but the politics killed everything, including developer freedom. Currently, at my work i have fair amount of autonomy and pretty much free rein towards design decisions, algorithms and implementation strategy. It is really productive, because this motivates you to do better every time, find more efficient and newer ways of solving problems.

            1 Reply Last reply
            0
            • F Fran Porretto

              Your experience is not unique, but the cloud has a silver lining: Managers are unlearning the most pernicious of these practices, under the lash of experience.

              The disease took its first form with the Capability Maturity Model (CMM), which, in essence, told managers that they could measure, and therefore control, the engineering "process." It was a lie from the very first, but it seduced an awful lot of "spreadsheet pilots" (my personal derogation for managers who think the complexities and sophistications of any engineering undertaking can be meaningfully measured or reproduced) into thinking they could guarantee something that God Himself has made un-guarantee-able: the ultimate functionality, overall cost, and time-to-completion of an R&D project.

              Matters became really grave with ISO-9000, which purports to codify how engineering should be done. In point of fact, the only thing about engineering that can even be described was summed up in the old "waterfall" description of a project -- and that description is notional rather than intensive. But the ISO-9000 enthusiasts (once again, managers with an unshakable conviction in the precise manageability of absolutely everything, even if it's never been done before, nor anything like it) were adamant. In this, they had backing from a number of large institutions, most notably the federal government, which made the ultimate cauterizing of the wound that much more painful.

              But the universe has its laws, and it grants no exemptions from them. One of those laws is that no one can nail down all three vertices of the development triangle:

              • If you rigidly specify functionality and cost of development, the time to completion will be unknown.
              • If you rigidly specify functionality and time to completion, the cost of development will be unknown.
              • If you rigidly specify cost of development and time to completion, you have no idea what the ultimate product will do!

              It doesn't matter what your "process" is, or how you've documented and explained it, or what rewards (or punishments) you've promised for following (or not following) it. Managers learned this by imposing CMM and ISO-9000 on us, and reaping the whirlwind.

              The best part of this is that the great majority of those managers thought their new management technique would make them look like aces in front of their customers, so, in the fas

              S Offline
              S Offline
              SeattleC
              wrote on last edited by
              #26

              I'm afraid I disagree with nearly every word of what you say. Some of my best managers pursued software process improvement in a thoughtful and effective manner. And ISO 9000 is a far more flexible tool than the CMM, allowing a variety of different processes to fit the specific industry and type of software being developed. The whole Agile movement (which has its own problems) is an attempt to repeat the dev process enough times that you eventually get control of it. I don't think this is the one yardstick that will measure the quality of a manager (ouch, meta-humor). This post needs to be the root of a whole 'nother rant. But I love your style.

              1 Reply Last reply
              0
              • S SeattleC

                It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?

                B Offline
                B Offline
                BrainiacV
                wrote on last edited by
                #27

                Except for one job and my current position as a manager, you just described my 35+ year career. I've worked at places where managers ruled primarily by intimidation. The fact that they were the managers made them inherently superior beings. Only one place comes to mind where the manager assumed you were an adult and knew what you were doing. He was fired as the scapegoat for disasters created by the salesmen. I missed him. The manager that replaced him was a complete idiot who felt he (or was told) he had to bring an out of control department back to order. As a manager now, I assume all my minions are adults who want to express themselves by doing their best. I understand that I will not be able to micromanage them because I do not have the time to keep up with the intricacies of their projects and development languages. But I do know how to smell BS in status reports. I feel everyone is unique and brings different capabilities to their projects. It is my job to find a way that their skills can be used optimally. It is also my job to act as facilitator as to make their jobs easier. And lastly, it is my job to council them with my life's experiences on how to avoid the common pitfalls in software development. I want code that is maintainable, not just cranked out quickly to spec. I want test scripts that are written to be used by people not familiar with the code. I want people who will collectively dream of creating code that exceeds the expectations of my management and our users.

                Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it. As suggested by GamleKoder... For efficiency, should not this read: Those who do not remember the past { are doomed to repeat it. cannot build upon it. } ;-)

                1 Reply Last reply
                0
                • F Fran Porretto

                  Your experience is not unique, but the cloud has a silver lining: Managers are unlearning the most pernicious of these practices, under the lash of experience.

                  The disease took its first form with the Capability Maturity Model (CMM), which, in essence, told managers that they could measure, and therefore control, the engineering "process." It was a lie from the very first, but it seduced an awful lot of "spreadsheet pilots" (my personal derogation for managers who think the complexities and sophistications of any engineering undertaking can be meaningfully measured or reproduced) into thinking they could guarantee something that God Himself has made un-guarantee-able: the ultimate functionality, overall cost, and time-to-completion of an R&D project.

                  Matters became really grave with ISO-9000, which purports to codify how engineering should be done. In point of fact, the only thing about engineering that can even be described was summed up in the old "waterfall" description of a project -- and that description is notional rather than intensive. But the ISO-9000 enthusiasts (once again, managers with an unshakable conviction in the precise manageability of absolutely everything, even if it's never been done before, nor anything like it) were adamant. In this, they had backing from a number of large institutions, most notably the federal government, which made the ultimate cauterizing of the wound that much more painful.

                  But the universe has its laws, and it grants no exemptions from them. One of those laws is that no one can nail down all three vertices of the development triangle:

                  • If you rigidly specify functionality and cost of development, the time to completion will be unknown.
                  • If you rigidly specify functionality and time to completion, the cost of development will be unknown.
                  • If you rigidly specify cost of development and time to completion, you have no idea what the ultimate product will do!

                  It doesn't matter what your "process" is, or how you've documented and explained it, or what rewards (or punishments) you've promised for following (or not following) it. Managers learned this by imposing CMM and ISO-9000 on us, and reaping the whirlwind.

                  The best part of this is that the great majority of those managers thought their new management technique would make them look like aces in front of their customers, so, in the fas

                  B Offline
                  B Offline
                  BrainiacV
                  wrote on last edited by
                  #28

                  At my last job we were forced to read "Who moved my cheese" and "Sojourner, An Insider’s View of the Mars Pathfinder Mission" (faster, better, cheaper mantra). The first, we guess was just to remind us that we were just rats in a maze and had us wondering if we should have continued the metaphor by leaving the sinking ship. (I loved the part of the book were the characters in it raved about metaphor of mice in a maze looking for cheese. Talk about rabid self-promotion...) The second, while it was supposed to be a blueprint for our software development (like plan on firing 10% of your staff for being incompetent), given that the two following space missions constructed with that methodology were failures, made the success of the first a statistical fluke. And to state your rules succinctly: Fast, Good, Cheap...Choose two.

                  Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.

                  1 Reply Last reply
                  0
                  • S SeattleC

                    It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?

                    M Offline
                    M Offline
                    Marcel Valdez
                    wrote on last edited by
                    #29

                    In the last two jobs I've worked at (in Mexico), developers pretty much were given a task, an arbitrary deadline and arbitrary requirements changes (with no reasonable rationale behind either), and then left alone until release and testing.

                    1 Reply Last reply
                    0
                    • T TestShoot

                      http://www.forbes.com/sites/venkateshrao/2011/12/05/the-rise-of-developeronomics/[^] Basically it says we are all nerds that don't know how important we are so acquire our talent and treat us like crap, we like it that way. Battered wife syndrome. There is a HORRIBLE gap in qualified tech leads these days. I just took over this process and found out that PM's don't know anything other than their projects (and they don't know them all that well) are the most important thing in the world, and web development is like using MS Word... it is too dorky and demeaning but they could easily do our jobs.

                      *--==[::tSc::]==--* TestShoot.com Film Supplies TBB aka P90X (my day job)

                      M Offline
                      M Offline
                      Marcel Valdez
                      wrote on last edited by
                      #30

                      That's why I'm planning on starting my own software shop where devs are the most important asset (a la Spolsky), I'm sick & tired of working 100 hour-weeks 3 months straight, and getting paid no overtime, not even a pat on the back. Fuck that.

                      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