Everyone’s been looking for silver bullets for so long they’ve forgotten what they set out to kill.
Practically everything has been floated as The Answer for solving the Software Crisis, a crisis that has been with us since the first hardware engineer said to the first software engineer, “Hey, I guess that all these gears, pushrods, pulleys and vacuum tubes and things are working now, so go do your stuff.” Hilarity ensued. From the very first time a software schedule slipped, methodologies for making cheaper/better/faster software have been surfacing and then going out of style like fad diets in trash Hollywood tabloids. You can’t open a trade magazine without seeing some article about how Co-Evolutionary Brisk BOHICA Design is going to take over the world next week and deliver everything on time, under budget and with fewer bugs than last month’s shining star, as well as making your teeth and underwear whiter (you don’t want to know how). Next month, Oprah will have her own methodology, probably based on deleting bloated source code after a binge of typing. You heard it here first.
Why are there no software methodologies based on suffering?
There are firms that practice ancient, mysterious rituals of development discovered during the time of Hammurabi. Peopled by cube farms packed with pencil-necked geeks, tracked by corridor-scale Gant charts and countless tons of obsolete documentation, and kept on the rails by people who have had their senses of humor surgically removed, these shops are no fun at all to work in, but you could do worse. Lots worse.
There are the Agile and Extreme folk, pixie-like and lighter than air, quick to pair up and argue politely over every semicolon. The basic model is to scrum and crystallize incrementally on a customer-guided path until the customer gets sick of all the churn, burndowns, velocity graphs, mocks and God damned flying Nerf rockets, cuts a check and tries to pick up the pieces once the fairies have been bribed to leave the building. These shops might be fun in the short term, but in the long term they’re about as stable as 60’s commune farming practices; you hear about the success stories, not so much about the ones felled by dysentery and bad drugs and unstable personalities. But you could do worse, lots worse.
There are the places using potent mixtures of CMM and Evolving Milestones and Comnet and RADiX and CORE and Accept and GenIus and Coherence and ABC and PAM and TSP and COMMIX and Jitterbug and whatever else fell of the truck and didn’t make it into a peer-reviewed paper in an ACM publication. If you lined all these methodologies up and shot one every second at the top of an ocean cliff, frankly you’d have a lot of people offer to help out, and probably make the world a better place, but have you priced ammo recently?
I maintain that this can be remarkably simple and straight forward methodology. No one likes to talk about it, but it’s already present to some extent on any project that matters. And look what it did for certain major religions. I think there is gold here, if you approach it correctly: You will suffer until the project ships, then you will suffer some more while customers bitch at you about what they got -vs- what they were willing to pay for. You will suffer bad tools and cheap hardware and arbitrary rules and abjectly miserable mail systems and mandatory weekend on-call times, and all the lunch places around your office will be clones of Der Weinerschnitzel and Hell Torito. Just shovel in food and soda and the occasional pep talk (“We’ll get you more comfortable manacles, better hammers and fresh batteries for the Happy Fun Tasers after the next milestone crushes what is left of your spirit”). But suffering with very, very good people in the trenches of the War Against Crap is not a bad thing, and I’ve had some of the best times of my career suffering and shipping just amazing stuff.
In short, the thing that the Silver Bullet proponents seem to universally lack is the simple ingredient of shared misery.
Perhaps this is implied?
And this, in a nutshell, is why I am not a manager.