Do The Simplest Thing That Won't Work

(or: Holy Shit, Mikey Drank The Kool-Ade)

My current employer is the only one I've ever worked for that has taken the process of software development seriously.

By that I mean that they understand it's a complex thing and have gone out of their way to seek out the people and ideas that really make it work instead of some management consultant derived crap-ass methodology involving nothing more than reams of "deliverables" with no real attachment to the product or process at all. (read: cmm,ss,uml,omt,etc...)

So we get guys in from Object Mentor and such places to sell and teach us about the various permutations of Agile programming and Xp.

Most notable is the practice of Test Driven Development. A few years ago I was hanging out on the One True Wiki, detecting the murmurs of TDD. I started applying it, or rather, trying to apply it. ...err... painful.

Eventually though I got the point. But wasn't quite motivated enough to do it on my own, especially without any kind of tools.

It's all about the tools.

So on Thursday I had the pleasure of getting a brain dump by sitting down with Mike Feathers from Object Mentor as he dragged me, kicking and screaming into pulling nunit into a...get this... C# .net GUI, to test code that heavily relies on 3rd party gui components, by instantiating those components (without a live interface) and driving them through code-based calls, rather than through normal gui clicks and typing.

This is something that other ... what do you call those, consultants? *shrug* have come to XPify us have been stumped by.

The end result is usually along the lines of "Well... split as much of the code out from the gui as you can, and test from there down." Made sense to me. Hell, I'm a network systems programmer. I don't even like LOOKING at guis, let alone programming them.

But we succeeded. By 3:00 in the afternoon, I was able to write a couple basic tests surrounding a new gui-based feature I was adding.

Now...

By 5:00, the fact that I had 5 such features to add, all mildly (though not substantially) different made everything perfectly clear.

I started by taking the tests, copying them and renaming them. Then the matter of refactoring the tests came up. I spent the first few hours of Friday cleaning up these tests into the front-end tests themselves and a bundle of support code.

This, my first serious foray into TDD, resulted in taking a piece of work that was no less than 3-4 days and squnching it down to 8 hours of working on tests, and 3 hours of working on logic. The result has a MUCH higher confidence rating than I could have gotten without the tests. NOT "would have", COULD have.

So let me zoom back in to the process for a second here...

The degenerate idea is that if you're going to write a piece of code, write a test first. You write the test (such that it fails) then you make it pass, then you evolve the code through evolution of the tests.

It occurs to me now that in evolving the tests that what you want to do at any given time is add a test that is "The Simplest Thing That Won't Work", then solve it with the far better known expression "The Simplest Thing That Will Work".

By switching back and forth between these two practices, you develop not only a body of code that you know works; but through the tests, a body of code that is fundamentally adaptable to new requirements and structural changes because it is anchored in the tests.

Plus, it forces you to constantly examing what it is you think you're trying to achieve and making sure you're on track with it. In addition to actually being functional proofs that the code works, the tests say "This is what I'm working on Right Now" at all times.

Until you've done it, this all seems like a bunch of crap. Maybe you've been burned enough to get to the point where "yeah, testing all my code seems like a good idea." But almost invariably what I hear (and swore up and down for a very long time) is "but the OVERHEAD!?! Shouldn't you be spending that time doing work?"

The answer, which I'm only going to briefly touch on here is that you don't have the faintest idea what work you're doing if you don't test. The work you're doing is "Build a house" and you're trying to figure out where to put a 2x4.

I'm a C++ programmer. I've been a C++ programmer since very soon after C++ existed. I love the language. It's low level, flexible and powerful. Plus, it's truly arcane in a way that appeals to my sense of order.

One of the things about C++ I love so much is that it's a thin evolution on top of c. When you write C++ code you know exactly what it's doing and when. There's no guesswork, no nonsense about garbage collection, who owns that reference, none of that crap.

As such there's a level of security that comes from writing your own libraries in it from the ground up. "I KNOW what this is and what it does." It's tough to beat with the fuzzy scripting languages, virtual machine environments, and all that. There's too much going on under the hood. Too many unknowns. (and don't DARE tell me "those details don't matter".)

I've a pet theory that I've developed in the last 36 hours about this: That this level of security is the source of a vast amount of bad practice in the software development world. Most notably the "Not Invented Here" syndrome, which really comes down to "I didn't write it, I don't know it, and in the time it takes me to learn it well enough to be as comfortable as I want with it, I could write it myself and know it better anyway."


The surprise of Test Driven Development (see, there was a point to that sidebar ;) is that having a body of 34 tests left me feeling secure about the quality of my code in a way that I did not at all anticipate. In the worst case, the WORST case, I have a bad test or I'm missing a test.

So from here I'm not sure where to go on my own stuff. Should I start pulling down pyunit, cppunit, junit, etc? And instrument all my code? (I have hundreds of thousands of lines of code.)

I actually think that might be a good idea. I have huge libraries that I've developed over the last couple decades. But as I've moved from interesting project of the moment to interesting project of the moment, my familiarity with these things has atrophied to the point where I look at the source directory and the few test programs I've got and I get this kinda fuzzy... "Yeah, but how well did that actually WORK?" feeling (resulting in "Not Invented Here" syndrome on my own code *sigh*)

Perhaps some of these projects and big ideas would be more tractable than I thought at the time if I could lock down the code under a comprehensive suite of tests.

*rolls up his sleeves and heads out to pick up a couple cases of diet dew*