The Blueprint

Dec 19, 2015

I listen to quite a few podcasts. Probably more than I should. Honestly, I delete most of the episodes. So I guess I could say I subscribe to a bunch of podcasts. One of those, Software Engineering Daily, recently had Seth Godin on as a guest.

I am a Godin fan. He’s not really a developer, but has some great things to say about business and doing your best work.

You should listen to the episode, it’s pretty great. Definitely some stuff that carries over to creating software.

One thing stuck out to me. Something I have been thinking about for a while. Seth was talking about how one of his companies needed an application built. So they created a spec, with design comps and details (I assume a functional document), and took those to an agency in New York.

They asked the agency how long it would take to build the app. The agency replied ‘three months’. Seth replied ‘Good. See you in three months’.

In today’s agile world, this seems crazy. But glorious.

Think about that for a minute. No scope creep. No changes unless a formal request is made.

But we know this doesn’t usually work. Seth Godin is the ideal client working with a top level agency in New York City. Defining scope before hand and forcing changes to be a formal request simply doesn’t work for many clients.

But maybe it could.

Something along the lines of a blueprint.

This is how engineers work. They design a structure, hand over a blueprint, and that’s what gets built. If there is a design flaw, it’s on the engineer to fix it. As a former construction worker, I totally get this.

I like the idea of a blueprint. A well thought out, defined requirements documents with a visual representation of what is being built.

I imagine a blueprint for a software project very similar to that of a construction project.