Blueprints

09/14/2005 11:03 PM by Chris Toohey

My neighbor scared me one morning...

We happened to be talking about the builder who built his home (he also built my home), when he told me a story. The gist of the story was this:

My neighbor has no rear-exit door to his home. He, after purchasing his home without noticing this decided to call the builder one morning and ask him a few questions about the home. It my was neighbor's intention to hire his own contractor to install a door in the back of the home, but the contractor advised that (apparently to retain the appropriate permits, etc.) my neighbor get the blueprints for the home.

My neighbor asks the builder for these blueprints, when he's told that he can't have them and is hurried off the phone. Persistence is not one of his shortcomings, as he calls back and eventually meets up with the builder face-to-face, all the while simply asking for the blueprints for his home. The builder, annoyed at this point, informs my neighbor that he cannot have the blueprints because there were no blueprints. After a few more words, my neighbor leaves. A few days later, the builder shows up at my neighbor's home, apologizes for coming off curt, and offers my neighbor a torn sheet of paper.

This paper was a torn page from a magazine. On this page was a picture, which was an identical replica of my neighbor's house.

My neighbor said that it took him a while to get it... but when he did he didn't know whether to laugh or cry. The home he had just purchased had only been built from the eye-balled schematics of a picture of a house. And he wonders why he didn't have a back door...

I'm a firm believer in blueprinting an application prior to it's development. Getting sign-off on a blueprint of an application not only greatly improves your ability to accurately provide a delivery timeframe (and rate, for you consultants out there), but also let's your customer know exactly what they're getting. It greatly cuts down on last-minute revisions to the application of the soul-shattering statements like "oh.... in my mind, it would've looked like this!"

Also, just seeing the application "on paper" can greatly help all of those involved. I know that by seeing the blueprint of the application in front of me, I can more accurately pinpoint potential issues or "dead spots" in the application. Having that blueprint will offer me a better vantage to code to resolve those "dead spots". A blueprint will also afford me a 10,000-ft-view of the application, and allow me to better structure and hone the overall application.

At the very least, it'll allow you to see that your solution doesn't have a back door!

Now, I know that blueprinting the application can take time, but I've always found that this up-front investment of time can save you towards the end of the project.

There's also something to be said for the architecture of a solution that doesn't require your development team to install LoJack in their loafers because someone in Marketing wants a new keyword... but that's a topic for tomorrow...