10,000 Foot Developer

I think finally the outrage against the manipulation of Agile methodology is coming to full head.

Years ago in discussions with colleagues we came to the conclusion that Agile had a built in flaw:  it allows people to manipulate the software management process for their own goals, and since everyone does not have the same goals, this creates conflict and in the end a bad product.

You can take note from this article by Erik Meijer: AGILE must be destroyed, once and for all.  This kind of angst is showing up everywhere:  let us just develop software, dammit, and stop micromanaging us.

Now certainly I understand that management needs a way to measure it’s field hands to assess productivity.  I get it.  I understand there have to be measures in place to assess risk and holes in software’s security, code stability, defect management and the like.  Agile has created a systemic problem whereby all this get’s bypassed.  How?

1. Agile management tools are picked to accommodate management, not software building.  The people who *buy* Agile are not the one’s subjected to it.  For instance, who decides whether to use Rally, Version one — heck even Git vs. Subversion?  rarely if ever a developer or even a 50% developing architect.  It’s almost always a manager, who is so far removed from the actual build process, who usually has less than a year of development under their belt and has been weeded out into management.  The tools have become so invasive to daily software making they are in the way.  One thing I hate is that it’s become so micromanaging that even style is part of the code checkin now.  You can say this matters (for python), but a tool eating up CPUs to see if I tabbed or spaced is a bunch of BS.  it doesn’t add to the supportability.
2. The open/communication aspect of Agile accommodates verbal people, but most engineers are spacial.  This means that in a world of constant scrums, reports, and social media that people who spend their time talking and writing get deference over people actually making the software.  Agile allows the complainers to get what they want.
3. Agile has created a booming industry for people who are snake oil salesmen.  So much money is being wasted on “evangelists” and speakers saying feel-good “yeah, I get it!!” talks.  Then are hired to parachute in with their Agile/Lean/Whatever methodology.  And you know what happens?  Same thing that happened to waterfall before.  The snake oil genies spend their time trying to make their system fit a business in order to sell it, laying on yet more layers of cruft in what might be an already unnavigable project management methodology.
4. Agile has de-individualized contributions, lessened innovation all while creating more paths of stupid accountability.  You can have a manager turn on all the metrics: Sonar, Cobetura, security checks, process, style checks.  All off line from the developer’s building efforts.  But in the end even after that the manager blames developers for anything that went wrong.  If a mangers are finding ways as to not be accountable, and are looking for tools to offload their responsibility then this is a culture that then pervades the entire industry.  The less developers willingly take on responsibility, the less they will want to solve the problems that can safen that responsibility, the less they will be innovative.
5. Agile tools were created to collect objective information but are now wielded by management against developers. When I first saw a scrum tool, I thought to myself: this will be used to measure and micromanage developers and rate them.  And now it has, but, it fails because you can’t measure intangibles.  For instance a person completing 15 easy tasks vs. a person doing a really difficult code task in many tools looks like a 15 to 1 score.  Some places even still use lines of code or checkin numbers to measure a “developer’s productivity.”  The intial creation of Agile management tools was so we, as developers, could improve of our own volition.  Sonar to decrease errors, SWAG estimates to measure and make our estimates better in the future.  Estimates are abused constantly; and you will now always see over estimation to protect developer’s behinds.

There are things that I like about the industry.  I like a lot of the testing, as long as it is used sanely.  I like the continuous integration engines.  I like some of the documentation things about projects in the new tools.  But I am not sure we are writing software any better or faster than a decade or two before.

One thing that burns me is the lack of objectivity in the industry and the winning by the “verbal” people to use religious and orthodox arguments to get to their goals.  This is . . . political.  Which means objectivity is out the door.  A great Ted Talk video explains how this happens in what is the holy grail of objectivity, the scientific method:

If objectivity has been removed from the process because the goal, good software, is put on the back burner so that political achievement can be obtained, well then, this is a weak methodology.  And software developers are no where near as objective as scientists try to be.  This kind of fundamental flaw pervades the processes of management, development, and testing.

Finally, so you sit down and make all these complaints.  And still, still, the biggest gap in all of this is that requirements gathering is *still* the number one complaint of all projects I am on.  Developers invented CI and analytic tools to make things better, but we haven’t seen a breakthrough in design and requirements gathering.

And that is interesting.  If Agile isn’t accommodating the processes of innovation, design, and requirements gathering then it isn’t accommodating its simply stated goals:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Personally, I’ve never bought into that utopic mantra.  I guess the manifestation of it’s failure is at hand.  Though, at least it was tried and allow to fail and we have gathered a lot of great learning and experience from trying.