The Baseball Development Methodology

Management and software engineering are still dark arts. Anything which happens to work is instantly picked up and turned into a cargo cult, spawning a flash ecosystem of consultants, training programs and seminars for the fad diet du jour. I will tell you how one of these got started.

In the late ’90s, managers all over America realized that most of their workforce consisted of slackers, with a couple of nerds called Dexter who actually got the job done. Now you don’t want to be a Vice President and confess at a board meeting that your empire, responsible for the company’s flagship product, consists of two guys called Dexter. You’ve got to have slackers to pad the numbers. With the flattening world, it made a ton of sense to outsource the slacking to India, where it could be done much more cost effectively.

This was a windfall for Indian companies like Baba Soaps & Outsourced Services (motto: “Trespassers will be recruited”). BS&OS was press-ganging far more people than could be absorbed in existing projects. The rough wooden benches lining the corridors to hold surplus personnel were perpetually overflowing. Benchies would hover around those fortunate enough to bask in the green glow of a terminal, solicitously ply them with beverages and wait for nature to come calling. Clearly, such a situation could not last. After a few episodes of the type which mortified Tycho Brahe, a new social order spontaneously emerged from the chaos. Groups of two formed, with each guarding access to the precious green light while the other did his business.

A visiting client from a US was intrigued by this phenomenon. “Why are they sitting in pairs? Don’t you have enough computers?” For an instant, his Indian chaperon thought of telling the truth – that computers were far more expensive than people. Despite Moore’s law, Indian family planning values (“The Moore the merrier”) still had the edge. He dismissed this moment of weakness and launched into an impressive spiel which was to make history. Well, a little bit, anyway. “Oh, that? We call it Pair Programming…”

And so the long day wore on… “How come you’re charging us for 10 QA engineers? We haven’t even finished the design yet!” Caught at overbilling, the Indian remained unfazed. He drew himself up to his full height and put on his best philosophical, idealistic expression. “How would you define a working product? One that passes the test suite, right? Therefore, creating the test suite defines the product, wouldn’t you say? Much better than a design document which nobody bothers to update anyway…”

The American had the last laugh, though. He took down notes, gave it a “cool” name – Xtreme Programming – and got rich.

There has never been a better time for starting another of these schemes. Managers in Big Companies have already experimented with all the management cults that exist, reorganized again and again, by product, by feature, by release, matrixed models, agile matrix models, with little visible success. They are looking for something, anything, which they can use to showcase as an example of strong leadership, being a change agent, and generally treading water for a couple of years until they get promoted to a different role or a different job, jettisoning their old responsibility like a spent booster stage and watching safely as it slowly falls back to earth. While they head onward to the fabled Moon, towards Cheese Everlasting.

You, too, can come up with a brand new development methodology and become a rockstar consultant, putting thousands of programmers in mortal peril. Just follow these simple steps:

  1. What goes ’round comes ’round. Pick something which was popular before the current incumbent. Agile’s ad-hocism was a reaction to the suffocating bureaucracy of Waterfall, which in turn was a reaction to Utter Chaos. So you’d do well to base your new development methodology on Waterfall, as a reaction to Agile.
  2. Insult the incumbent. Notice how Agile vendor presentations use words like nimble, quick, innovative to describe their own brand of poison, while dismissing older methods with words like regimented, slow, silo-driven, etc. Draw adoption curves showing where you are positioned. One Agile presentation I’ve seen even had helpful pictures of dinosaurs near the Waterfall (“obsolete”) end of the curve, and lightning bolts at the Agile (“leading edge”) end so that even your manager would get the hint.
  3. Make a Web Thingy. Web 2.0 thingies are all the rage now. There are Scrum tools which are so basic that they won’t even let you track dependencies, but you’ve got to buy and use them because they’re all Agile and Web 2.0 and stuff. You’d do well to draw on the reservoir of black hatred enjoyed by Microsoft Project and come up with a simplified Web Waterfall Thingy.
  4. Last and most important, Use a sports metaphor. Even the few sensible American men who are lukewarm about sports have to pretend to be rabid fans, on pain of having their testosterone levels becoming a matter of public debate. So you simply can’t go wrong using sporty terms to re-label all the concepts you’re ripping off. This will give the illusion that you have invented something new, confuse your detractors, force them to use your terms and make their arguments sound silly, while providing your supporters with a ready fund of sports catchphrases and anecdotes to distract the audience. Thus, Agile calls a meeting a scrum, a project manager is a scrum master, you have sprints.

Agile has already taken Rugby, so we’ll have to find another sport. Preferably American, since they’re still the largest market for this kind of mumbo jumbo. Baseball admirably fits the bill. It’s a team sport with an extensive jargon of its own, which can be mapped to software development terms. For instance, if you are going to create a Waterfall-like methodology, try this:

  1. First Base. Initial investigations, Project overview, Requirements Analysis. Generally get a feel for the issues at hand.
  2. Second Base. Detailed analysis of various features, flesh out one or two prominent features.
  3. Third Base. Rapid Prototyping, Simulation.
  4. Fourth Base. Frenzy of Development, Quality Assurance, finally culminating at RTF (Release to Fulfilment).

I’m sure you can find your own creative uses for other baseball terms. Like inning to replace sprint. Remember, no matter how crazy it sounds, no matter how many silly gimmicks you add (make everyone wear coloured baseball caps), it will find adherents. Even the most ridiculous religions and open source projects find devotees, much to the surprise of their founders.

Go hit a homer!

Advertisements

3 responses to “The Baseball Development Methodology

  1. Heh! Moore’s law, Moore the merrier. Good one.

    The baseball metaphor would backfire though. Refers to dating first.

    To throw in a little bit of defense, I have to say things do tend to improve underneath the cycles. There is slow ramp curve of growing enlightenment (mainly towards the realization “entropy happens”) underneath the wild swings.

    For example, the original Waterfall type thinking (pre Brooks, “Mythical Man Month”) really was rather like a creaking dinosaur. Then ‘pure’ agile a couple of decades later started to look like brownian motion. Now people have noticed you need a bit of both and getting started with the content-free tradeoff tautologies. But soon there may be an actual creative synthesis that says more than “well, you have to plan, but you also have to be agile.”

    But overall, I agree, software complexity has no easy fixes. Stuff is going to be crappy for the first few times around, and eventually somebody will do it right for the first time. Every new piece of s/w in every generation involves discovery of new information, and during that discovery process, things are going to be crappy no matter what you do. Once you’ve learned, nearly anything will work because it’s been figured out.

    So to invent a new methodology, the next guru needs your ideas, but also a “proof case” that would have worked no matter what method you used.

  2. Hi Venkat,

    the article was written tongue-in-cheek, with gritted teeth (Try doing that and watch your expression in a mirror – you’ll have an approximate idea of my frame of mind).

    There were certain developments at my workplace which I strongly disagreed with. Now I could have done some thoughtful analysis, painstaking research, identifying the problems and suggesting potential solutions.
    Or I could simply vent spleen in the easiest and most content-free manner possible.

    I have since resolved to kick the habit – satire, I mean. Too easy these days, since reality so closely approximates good satire that it’s hard to tell the difference.

    Agile’s gratuitous renaming of standard terms with sports terms really got my goat. “Why..” I thought, “this is as ridiculous as using a baseball metaphor, with the fourth base indicating the point where the project got-” So yes, the dating metaphor was how this article actually got started. Go back and read it 🙂

    Tinkering with development models is all well and good. Like extracting an extra mile per gallon. But the problem with most projects is not the car, or the efficiency of the internal combustory processes, or the driver, or the passengers. They’re on the wrong bloody road going to the wrong bloody place.

  3. Pingback: McDonaldization of Society and Coolification of Professions « Dmr->blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s