April 17, 2010

I Have A Dirty Secret. I'm A Software Craftsman

I have a dirty secret.

No, it's not the one about the Nuns and the winter vegetables. It's even worse than that.

I keep it off my CV and I never, ever mention it to potential employers when seeking contract work.

To my shame, and despite my best efforts not to, when I write code I routinely achieve very high test assurance. We're not talking 70% of the code or even 80%. No, we're looking at a truly obscene 95% or higher. And I'm not just talking about code coverage here. No, I graduated from that years ago. This is the hard stuff. I actually test my tests. I always run them to make sure they fail when they're supposed to, and I often use mutation testing to seek out any gaps in my tests, and once found, I just can't help plugging them. (I think someone might have just fainted. )

But it gets worse. My depravity doesn't stop at test assurance. I'm addicted to simplicity. Take two if... statements into the shower? Not likely. I like to Extract'N'Go. I get the cold sweats when I see methods longer than a few lines of code or that do more than one thing or have more than one branch. If the code's written by me, you'll find no methods longer than about ten lines of code, and vanishingly few with a cyclomatic complexity greater than two.

Oh, the humanity!

But it doesn't stop there. I'm obsessed with making my code readable, even to non-programmers. Try as I might, I just can't seem to get the hang of variable names like "t" and "x" and "m_strFltYrpOxfyRtn", method names like "returnNonNullString()" and "do()", and class names like "HelperManagerUtils" and "AstractXmlVisitorFactory2". I've just got this mental block. I can't help thinking my names should have something to do with the problem the user wants us to solve for them. I know. It's crazy! I've even tried using comments to hide my shame. But I can never think of anything useful to add that isn't already obvious from reading the code. EPIC FAIL.

This affliction of mine has now entered an advanced stage of perversity. If I could have just been satisfied with simple, readable and well-tested code maybe I could have controlled it. But, noooo. That wasn't enough. I had to go and get myself mixed up in the whole "coupling and cohesion" can of worms. So my code isn't just simple, readable and tested. Now all my classes and packages are loosely coupled and cohesive, too. And I'm not just talking about a bit of "tell, don't ask" or the occasional "dependency injection" here, either. This is the full-blown Object Oriented Design Principles (and then some!) shooting match: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion, Law of Demeter, Acyclic Dependencies, Stable Dependencies, Stable Abstractions, and a few I made up myself (because after a while I just wasn't getting the same high from the old stuff like I did at the start.)

Of course, I never mention any of this to prospective employers. They'd have me marched out of the door faster than you can say "perfectionist" (if you'll pardon my French). You only have to search on the big IT job sites to know that code of this quality simply will not be tolerated. And quite right, too. Software development's hard enough for the average team without some deranged OCD-type rampaging through the code like a bizarre kind of reverse-bull-in-a-china-shop, making it all nice and neat and maintainable. Especially, if, like me, they don't even have the decency to take a lot longer to deliver features while they're doing it.

The bottom line is that we're all on to a good thing here. I totally understand. No team is going to want someone like me producing high quality, reliable software. No team is going to want someone who can keep on producing valuable new features and responding to evolving business needs month after month and year after year.

It's that sort of nonsense that just gives customers ideas. And that would never do, now would it?

Posted 4 years, 4 months ago on April 17, 2010