January 2, 2015

...Learn TDD with Codemanship

The Unimportant Code That Turned Out To Be Critical

Just time for another sneaky peek at one of the topics covered in the new Advanced Unit Testing course from Codemanship...

Since it's around that time of year when we traditionally tell ghost stories - at least, we did in the days before the Eastenders Xmas omnibus - here's a short scary story about The Unimportant Code That Turned Out To Be Critical.

It was a few years ago now; an IT organisation serving a large business with offices all around the world. Some bright spark had written a really useful library of actuarial functions on a quiet day. There was no project, no budget, no strategy, no requirements, no plan. Everyone was out at the Christmas party and he just thought "Hey, I know what I can do". And he did went and done it.

The library was used on the project he was working on, and they saw that it was good. So it got reused on other projects. A lot.

Before you could say "Enterprise Architecture", these 1,000 lines of very useful code were propping up millions of lines of important business code.

But his library was just a little something he knocked up one afternoon. It had no automated tests. It had no build script. It was not being maintained. It was done with scant regard for how readable the code was, or how simple it was, or how easy it might be to extend or replace it.

From the perspective of developer standards, it had slipped under everyone's radar.

And now there it was, a little kernel of code they didn't give a second thought to that was a foundation stone for almost all of their systems.

Any builder will tell you about the importance of strong foundations.

Much talk there is of dependencies in programming, said Master Yoda. But little or no talk about the importance of reliability in the things we depend on. That, too, has slipped under our radars as a profession.

Here's the thing: when a chunk of code - a method, a class, a component, a system - is heavily depended upon, we need to take extra care that it is proportionately dependable.

If we visualise the call stacks in our software - at any scale - as chains of dependent modules collaborating to achieve some goal, then that chain is only as strong as its weakest link. And if we include one link in many chains, that link needs to be especially strong, because it becomes a single point of failure that, when it does fail, breaks many, many chains.

And so it is that a single bug in the actuarial library broke many, many use cases in multiple systems when it finally jumped out and said "boo!", and the whole house of cards came tumbling down late one Saturday night.

That's why it pays to be aware of the real dependencies in our software, so we can target our efforts to make them dependable enough more accurately.

if you want to get a bit more in-depth about it, read my Dependable Dependencies Principle paper.

And, remember, don't have nightmares.

Posted 6 years, 6 months ago on January 2, 2015