March 7, 2012

...Learn TDD with Codemanship

But What About Your OTHER Code?

While it's becoming fashionable to take more care with our source code, many teams have a blind spot when it comes to their other code.

"Source code", to many, means code written in familiar programming languages like Java, C# and Ruby. I have a wider definition: "source code" is any data - textual or otherwise - that is necessary to create a correctly functioning software system.

If changing it can break the system, then it's source code, as far as I'm concerned.

Take build scripts, for example. Do we see these as source code? Many don't. But a change to our build script could lead to it building broken software.

Or what about configuration files and databases? Could changing a config setting break the software? Sure it could.

Or how about our Hibernate mapping files? Or our MVC mappings? And what about our automated test scripts?

Teams can make the mistake of thinking, with tools like Hibernate and Spring, that they're getting something for nothing. By not treating other kinds of system configuration data as "source code" - and applying the same discipline to creating and managing it that they would to, say, their Ruby code - they can sleepwalk into a very rum situation indeed.

I'm now in the habit of test-driving things like build scripts and Hibernate mappings. I evolve them in small tested steps, and I make a point of keeping them as simple and readable and free of duplication as I can.

Because I've learned from bitter experience that when your other code is difficult to change, then your software is difficult to change.

Posted 1 week, 6 days ago on March 7, 2012