I have been at this for over twenty-five years and it amazes me that the same dysfunctional interactions between management and development teams continues to play itself out over and over again wherever I go. It never fails. Management asks for an estimate and development sandbags. What then follows is a negotiation that has all the honesty of a B-movie Cairo street market argument between a merchant and a customer. I almost expect one side or the other to exclaim, “You’re keeling me! Have mercy, I have two wives and nine children to feed!”
As if the actual time and cost for the engineering, testing, and documenting of a piece of software can be haggled over like the price of a bag of dates. And as if the actual time and cost for the engineering and testing of a piece of software can been known before it is completed. That’s the dirty little secret, never openly admitted by developers and never fully understood by management. Yet we all know these following truths:
- Software is always late, or
- Software always sucks, or
- Software is always late and always sucks.
Providing cost estimates for software development projects has always been the most difficult, twitch-inducing tasks for a development team. The difficult of predicting what will happen during the course of a software development project was well-documented in Fred Brooks’ classic The Mythical Man-Month in 1975. Brooks identified certain dysfunctional patterns of behavior that continued to repeat themselves (and still do), from one project to another. One such pattern is adding people to try to get done sooner. This can be done when a project is late, and I have never seen that do anything but make it even more late, but it can also be done before the project has even started, during the horse-trading that goes on during the development-management negotiations. When cost and time estimates are expressed in terms of person-days, the response back from management often is “Can’t we just hire some temporary contractors and get it all done sooner?” That question by itself is an indication that management is focused on only one measure, the release date, and is ignoring, at least for the moment, the cost of developing the new release. They might well be fixing on the release date because they are chasing some sales opportunity that has already been lost.
Aside from this faulty business logic, there are the basic assumptions that all developers are interchangeable (which is how Bangalore has become the software development labor capital of the world), and software architectures have a fluid number of equally complex components that can be doled out to any number of software engineers. Both of these assumptions are patently false, yet they continue to be held by otherwise very smart and capable business executives. I blame it on the in-flight magazines they read.
The common analogy that is used in trying correct this misconception is “One woman can have one baby in nine months, but nine women can’t have one baby in one month.” This one gets used so often that it has become a cliché. The executives listen, chuckle, nod in agreement, and then say, “Can’t we just hire some temporary contractors and get it all done sooner?” I’ve tried to provide an even more graphic and frightening analogy: “One surgeon can remove your appendix in one hour, so six surgeons can remove it in ten minutes, right? How’d you like to be lying on the table looking up at six guys with knives in their hands?” That one doesn’t work either, but it does relieve me of the responsibility of attending further meetings.
The basic power-imbalance of these situations leads the development manager to become defensive and believe that the executives are questioning his or her competence and maybe even their loyalty to the enterprise. Whether or not this is true, what usually follows makes the situation worse. The development manager then tries to educate them by explaining in excruciating detail with Gantt charts and dissertations on software development best practices. Eyes glaze over, and if they didn’t distrust the development manager before, they do now and start thinking about that voicemail they received last week from an offshore development company.
As the cynicism and mistrust grows on both sides of this discussion, the dysfunction increases. The development manager promises to go back and work with his team to “re-jigger” things. This cycle repeats itself several times, and miraculously, a release date is found that both sides grudgingly accept. Unfortunately, that date is too late to meet whatever market opportunity the executives were chasing and too soon for the development to actually build and test the software.
And the death march commences.
There are lessons learned on both sides. Executives convince themselves that developers don’t care about business realities and want to avoid accountability by making techno-babble excuses, to cover their asses. Developers convince themselves that executives don’t care about the immutable laws of physics and mathematics and demand magic compressions of time. They feel bullied, become disengaged, and rather than focusing on creating great software, they focus on covering their asses. Future development estimates are not based on the the results of detailed problem analysis and sound judgment, which will be ignored, but based on what’s the biggest number we can think of that won’t get us fired. After the negotiation, if we’re lucky, the date might be a date we can actually make. This is extremely inefficient because due to the defensive padding, the agreed upon date is probably later than it would otherwise would have been if the development team wasn’t functioning in CYA mode.
This is learned behavior and it is nearly impossible to change once this cycle has occurred only once. Fixing this dysfunction is a long process that requires both sides, after having been taught to distrust one another, to be willing to begin granting trust again, or in really bad environments, for the first time.
© 2010 – 2024, Bob Baldwin. All rights reserved.
