Software Thinking

Most mornings I try to check out the interesting new links on the particular categories of Reddit that interest me.

For the most part, I don’t bother with the comments–they are generally noise, not signal.

However, the best computery thing I read last week, and possibly for a significantly longer window, showed up in one of those comment threads. And the issue raised is something that’s been particularly irksome for me this week in a couple of cases.

I’m going to quote the entire comment that particularly thrilled me, but the whole discussion running on from this comment (which can be read here) has a very high signal-to-noise ratio.

Here’s the bit I loved, with props to “Shaper_pmp” for putting down very clearly something I am always going on about–if he had included the bit about being able to traverse different levels of abstraction within the model during design and problem resolution his comment would have sounded like me on a rant:

Many of the worst implementation errors come from people who put coding ahead of understanding, and make mistakes that they wouldn’t have if they had a proper model in their heads. 🙂

This is something I’ve been thinking about recently – most of the bugs and problems I see caused by junior developers at my workplace are a simple result of not having a model of the software in their heads.

There are two ways to modify someone else’s code – the black box and the model.

Black-box coding is easy – you just modify the code, note the output, modify it a bit more and call it finished when it doesn’t give any obvious errors – you’re basically just poking at the system with a stick until it seems to be going roughly where you want it to go. It’s also terrible programming:

• You don’t have a good idea of how the code works, so it’s easy to introduce bugs or miss areas when testing.
• It slowly turns code into unmaintainable spaghetti-code because you’re only considering one small region in isolation, rather than considering the whole state of the system, and how to move it back to the desired state.
• At the end of it you have no real idea if you’ve fixed the problem or just fixed the symptoms.

Model-based programming requires that you effectively load the entire system in your head, so you can simulate it there to work out where problems actually come from (and redesign the system to eliminate errors, rather than simply slapping on sticking-plaster fixes and moving on).

Model development is a lot harder than black-box – it takes more effort, ability and concentration to “think yourself into” the program, and it requires greater familiarity with the codebase. It also typically takes longer to skip from one project to another, as it can take up to an hour or so to really load a new system into your head to the point you’re making progress at full speed.

However, it also produces much, much higher-quality code, more elegant design, fewer bugs and a greater confidence that the resulting system works correctly.

It’s the difference between thinking “hmmm, this function is throwing an error because it doesn’t expect this variable to be undefined, so I’ll set a default for the variable if it’s undefined to make the error go away” and thinking “”hmmm, this function doesn’t expect this variable to be undefined, so I’ll track back up the call-stack to locate the unhandled edge-case and find out why the hell it isn’t defined already, and if it’s appropriate to give it a value somewhere, or if we should have handled this entire case a different way”.

One is slower but leads to more beautiful, reliable, maintainable systems and the other is quick, but leads to an unreliable, unmaintainable spaghetti-code nightmare.

Annoyingly though, managers often prize the black-box poke-it-with-a-stick method over the model, because they’re often fundamentally incapable of assessing code-quality, but the black box method is quicker in the short term.

Preach it.