Who moved my thumbscrews?

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?

So: Suffering.

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. :-)

This entry was posted in Rantage. Bookmark the permalink.

8 Responses to Who moved my thumbscrews?

  1. Ben says:

    It is my experience that most engineers know how to do something properly so that it will not break or be riddled with bugs, but they have one or more of the following issues:

    a) They don’t believe that they will be given the time to do it properly.
    b) They don’t believe that they will be paid differently to do it properly.
    c) They don’t enjoy doing it properly (more fun to do it badly).

    Up the chain of management, nobody wants to pay what it really costs to do it right, so the false economy of saving time at the beginning to pay back 10x as much at the end will rule.

  2. Pierre Paré says:

    I guess you don’t know about Microsoft error reporting program.

    http://www.updatexp.com/we-share-your-pain.html

  3. John says:

    You sound like my father who is a manager.

  4. Pavel Curtis says:

    Man, nobody rants like you rant. Truly, it’s inspiring to us wannabe curmudgeons.

  5. Adam says:

    This is exactly why you *could* be a manager

  6. Hagus says:

    Great post!

    Here’s another dirty software development secret – the ones who are truly prepared to suffer and sacrifice themselves, are also the ones who enjoy that pressure the most. And they’re probably your best programmers.

    Pair them up with a manager who knows not only how to push them, but when to push them and when to let them relax, and these guys will keep going forever.

    Software development is exactly like training for sport in this respect. Interval training is what gets you the best results because it pushes you past what you thought you could do, and it simulates the extremes you’ll suffer when you go head to head against a team of people just as hardened and motivated as you. Only certain personality types experience this pain and say “that was awesome, sign me up for more!”

    Of course, nobody likes to suffer for no reason. So everyone from your direct manager through to your CEO had better be ready to sign up for this stress and stand right by you. I think properly cultivating a “corporate culture” (I loathe the term, but what else can you call it) like this is an absolute foundation stone for being the best shop in the game.

  7. Pingback: A Software Development Methodology Based on Suffering « Stone Monkey

  8. Ikemay Urrykay says:

    Ah, but you have left out a motivation for withstanding the suffering. Why go through the suffering? “To build Great Software!” But what if your shop isn’t concerned in the slightest about building Software That Works, much less Great Software? Why suffer then?

    Do the best people suffer for financial rewards alone?
    Are they willing to suffer merely in order to have built Great Software?

    I’d be willing to bet it’s a combination of the Great Software and Great Monetary Rewards that motivates many people to withstand the aforementioned Great Suffering.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>