Us vs. Them
I am a software developer (or programmer/analyst, if you wish). Over my 20 year career i’ve flirted with management positions a number of times. I’ve been a project lead developer (as I am now), i’ve been a team lead with several developers working for me, i’ve even been an IT manager with a budget and employees (in an IT department of 5). But, mostly, i’ve been a developer, probably 16 of the 20 years. Writing software is the reason i’m in the industry.
I am always wary of efforts to seduce me to the dark side (management). I find that I don’t think like most of the managers i’ve ever had. I laugh at jokes that make fun of managers or the corporate bureaucracy. And I find that I have a strong bias toward the developer side of the argument, no matter the subject. No matter what the management edict, I question and push back before submitting willingly. I question the reasoning of management decisions, or the source of management facts and information. It’s just the way I’m built.
This leads me to the inspiration of this post: The Gartner Group (The Big “G”, or GG). I work for an organization with about 900 employees in the corporate HQ. The are about 130 folks in IT.
My coworker and friend (see his posts about the Pacific Northwest Software Symposium, where we ate some excellent Pad Thai, and talked about Microsoft, Open Source, and Robert Scoble). Have been discussing the role of Gartner Group in our organization. When we have discussed this with a mutual friend and member of upper IT management, there is clearly a wide divide between us (the developers) and them (IT management).
Our first reaction when there is a mention of Gartner Group is pretty predictable. We roll our eyes, and let out an exsaparated “Puh-leeeze!”. My actual contact with Gartner Group has been limited, a teleconference or two, and a few too many white papers, and far too many web stories with Gartner Group quotes to back up one claim or another.
In our organization, Gartner Group is the first stop before any decision making takes place. Management wields Gartner Group information like a bludgeon, justifying any inane decision with a white paper, or analyst quote. The developers are instantly on the attack when the Gartner Group club is pulled out.
It’s all about trust. Management trusts the large, well funded, analyst organization that provides wishy-washy and vague guidance that can be spun to fit any organization. Developers find such organizations without credibility, because they are populated by people who aren’t fighting in the trenches with them. They are in nice window offices, wearing suits, and fiddling with Blackberries, just like our managers. They are one of them. That’s why we trust Slashdot, Digg, Joel On Software, and that Java developer we met at a conference who has a blog. They are us.
Self Inflicted Pain, Part II
In my previous missive I examined how we, the developers, had created our own implements of torture to apply to ourselves. I just received the final draft of the documentation standards from our internal team. It covers most of the expected things, why we need docs, why we need well written docs, where to store the docs, and most importantly, the list of required docs.
The required docs list is a matrix with the doc list on the left and across the top the types of development products (web service, portlet, jar file, etc). At the intersection of doc and product is a single letter code indicating whether the doc is required, optional, or occasionally required. As I expected there were no optional docs and only one that had occasional applicability.
As I read further the document went on to discuss the processes surrounding the production of the required development documents.
At the end, the last paragraph concedes that with time pressures on the development staff being what they are, we won’t actually have time to write all of the docs on the required list. So, it specifies a short “really” required list. That excludes the one document that is actually required to get an application deployed to QA or production.
It only took 5 months to write this 6 page document.
The Iron Triangle Still Rules
I’m in a session titled ‘Real World Agile’. It’s an introduction to the how’s and why’s of Agile development. One of the attendees wanted to know how Agile would help in his environment where they had a fixed required list of features and a hard deadline. Failure could torpedo the company. It was clear to me that he (like many) either hadn’t heard of, or wasn’t aware of the ‘Iron Triangle’ principle. This principle basically says that you can only control two of the these three items in a project: cost, scope, resources (people). If you have a fixed cost budget, and limited resources, the scope will have to change to meet the budget with your fixed resources. The resource element of the triangle can be people, hardware, software, etc. Scope can be a feature list, requirements, or an acceptable level of quality.
Software methodologies exist to manage the constraints of the Iron Triangle. Agile development is the latest in a long history of methodologies (and Agile is really an umbrella term that covers a number of methodologies) that hope to make it easier to manage to successfully complete projects.
Remember: You can’t have it all.
