Builders vs. coders.

When I first started in the software industry at Teleca they used a piece of software called KMS Project Base to track their customers, opportunities and projects. It worked well but had loads of options we never used – price per square foot amongst others. When I asked the sales director he told me that this was because KMS was owned by a mate of his in London and was designed for the construction industry. CRM is pretty universal though, so Nick decided to use it for software consulting as well. In fact, it worked so well that when Steve and I setup our own business a few years later we decided to keep using it.

The point is that making buildings is a lot like making software. Queue cheesy analogies:

  • You need a good architect so it doesn’t fall down once people start using it.
  • Sound design to make sure you’ve thought about all ways it will be used and considered how the parts will fit together.
  • A solid foundation to make sure it can take the weight that you place on top.
  • Professional, well trained engineers and specialists who will construct each part with suitable quality.
  • Good project management to make sure you deliver it on time and on budget.

This is clearest when things go wrong and we can think of examples for most of these:

  • idiot_77If your architect makes a miscalculation then you’ll have problems either during construction – or worse, once your users get started.
  • If you didn’t do designs up front then you’re likely to discover all sorts of problems and incompatibilities during the build causing you to rethink or redo work you’ve already completed.
  • If your foundations are not well planned then as you start adding new floors (features..) then things will start to crumble.
  • If your engineers are not well trained then they’ll struggle to build to a suitable standard. You’ll spend all your time micromanaging, making them tear it down and do it again, or worse, not discover problems until after the client moves in..
  • Without adequate project management you have no idea where you are and whether or not you’re going to finish on time. You may end up paying extra to get your staff to work weekends and risk burnout or overspend.

Sound familiar? A few quick specifics..

Let’s say you’ve finished your electrics but your sparky has not done any documentation. Your customer wants an extra couple of lights in the living room and you need to figure out where to connect them. Where do you pull up a board? Is the cable in the wall? You take off a panel and there’s a rats nest of wires, with no labels (or comments) and all you can do is try a few to see what happens. Who’s ever switched off the kitchen circuit but that one socket by the washing machine stayed on?

How about in software? We want to add a new option to our menu but we’ve no idea where to plug it in. There’s no design doc and when we do find the source file there are no comments, we’ve no idea what where to put it, or worse, there’s one massive function with a ton of strange conditional logic so we’ve no idea what the impact will be if we add another option.

Lets say you just dived in and started building. “No time for design!” said the foreman.. You put in the groundwork, lay the foundation, start building up the walls and get to the bathroom. Oh. The pipe doesn’t line up – we thought the bath would be in the corner but actually it doesn’t fit. We could put in a shower instead but that’s not what the client wants. Shit. We’re going to have to dig out a couple of meters of concrete, redo some groundwork and then move one of the walls. Ends up taking much longer than it would if we’d actually done the drawings in the first place.


And in software? We jump in and build a framework to draw our 2d shapes. Now we want to save them – no problem, we’ll just serialize them as points. Ah. We actually need to represent them in 3d so we can do a transform but our framework only works in 2d. We spend the weekend rewriting it but when we push it out on Monday it turns out the new files are completely incompatible with the old ones and our users have corrupted their drawings. Damn. Looks like we’re going to have to spend a few days writing a file converter.

Not only is it common sense, but there’s plenty of readily available research to show why we run engineering projects the way we do. So get over it, a little bit of short term effort in something you don’t like as much pays dividends in the end.


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: