Digging a Hole and Covering it with Leaves — The Software Development Version

Dietrich Kappe, Tuesday, June 30, 2009 @ 5:30 am

photo credit: Marco Arment

Whenever I hear the plan uttered (and in my Wall Street consulting days, I heard this a lot), that we should build an HTML (or Flash) prototype, impress the client and then fill in the back end, an unwanted image comes to mind. We're digging a hole (the missing 80% of the back end) and covering it with leaves (the HTML prototype) in the hopes that the client will fall in (impressing the client).

No, this isn't a rant about HTML, Flash or paper prototypes. Those have their place, to be sure. We use them every day in our own software development practice, but they have a short lifespan -- usually less than an iteration on the way to delivering the actual feature that it is prototyping. But when the prototype takes on a life of it's own and becomes a long-term deliverable, that's when you run into problems. What are these problems? They aren't as numerous as fall leaves, but there are plenty.

The View from the Bottom of the Hole

1. The client thinks you're practically done.

The interface is done, right? So you're practically done, no? Well, no. The sort of unsophisticated client that confuses a slick UI for a working system, is not going to have a lot of patience when you explain that you have to fill in that hole with the actual backend and that will take four times as long as the UI you just sold him. This can lead to...

2. The rotten foundation, or, get it done quick.

photo credit: adamjackson1984

The pressure is on to complete the back end, so you cut corners and slap together the system like the fake town in High Plains Drifter. The resulting software, like all rush jobs, will be hard to maintain and not win you any points with the client.

3. You can't get there from here.

You've developed some really slick interactions in the prototype. Now in building the actual system, you discover that your idea of a transaction doesn't line up with transactions in some third party system you have to integrate with. You either have to change your interface (time for another layer of leaves!) or try to paper over this difference with a likely complex faux transaction layer in your back end. Blech!

4. We propose, but we don't actually do anything.

Regardless of how high fidelity your prototype, it probably didn't actually do anything. Otherwise, you could have actually developed working software in that same time period. If the prototype just looked good but didn't do anything, there was no opportunity to put it in someones hands and see if it did the job. You end up with something that looks good, but likely doesn't fulfill the needs of the prospective users of the system.

The solution to this mess? Don't develop software this way. Deliver working software every week or two and check against real users to make sure it does the job. If you're in a hole, stop digging.

Related posts:

1. The Origins of Software Engineering Economics — You are Ron Turcotte
2. 800 on Your Math SAT, Software Development and Bugs
3. Software Development and Wasted Motion
4. The Five Deadly Sins of Software Development
5. Ten Keys to Successful Software Development: #10: Tools and Infrastructure

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment