What the Underpants Gnomes can teach us about Software
Posted by Patrick Angeles on December 12th, 2006cartoon episode involving Gnomes that introduced us to the following three phase business-plan:
1 Collect underpants
2 ?
3 Profit!
We’ve seen variations of this plan, both real and fictional. The point being, it’s easy to identify the beginning state and the end goal. It’s not so easy to figure out how to get from one point to the other. For this blog, I’d like to introduce a variation that applies to software development. It goes something like:
1 Collect requirements
2 ?
3 Profit!
Software engineers that survived the dot.com bust are quick to recognize this all-too familiar scenario. Apparently, some companies thought that Step 2 involved hiring a bunch of software engineers. After all, if you hire enough smart people, you just might find someone who knows the answer to Step 2. Unfortunately, throwing money at a problem is a bit like torture: it might get you an answer, but it’s not necessarily the right answer. It may result in actual running software with buttons, levers and flashing lights, but it may not solve the problems at hand.
That said, there are development practices that aim to demystify Step 2. They go by fancy names like Rational Unified Process, Extreme Programming or Scrum. I won’t go into the merits or drawbacks of each of these, as their respective proponents debate enough amongst themselves. But I will say that one common theme is to stress expertise, communication and iteration. Expertise means there should be at least a few members of the team with industry experience who know what they are doing. Communication is important, not just between team members, but business stakeholders (the people that use the software). And Iteration says that producing great software is not one sequential well-planned journey. It should allow for revisions on the initial design, based on incremental releases and feedback by users of the software. So rather than a three-phase plan, we have something that looks like the following:
10 Collect requirements
20 Determine the issues
30 Design the solution
40 Implement the solution
50 Test the solution
60 Have users evaluate the solution
70 Goto 10
This is a basic (heh) way of saying that the production of software is not a one-time goal. It is a continuous and gradual--dareisay evolutionary--process. For the non-geeks who don't really give a damn about the product side of things: I'd like to point out that this is the case not just with building software, but also in selling it. A good solutions vendor should be a proven expert in the field, is willing to communicate with the client, and provides an evolving roadmap based on client input.
Disclaimer: I own IBG stock.
