Running away from a problem by running towards it.
I'm getting cranky today because I'm trying figure out the behavior of some code that's NIH but I have to support. I'm not having much luck because I can't reproduce the root error that's causing my error handling stuff to work right. Starting to get frustrated, I decided to take an actual lunch break and do something refreshing: read.
And what was at the top of my reading stack?
Test-Driven Development in Microsoft.NET.
Wow, I'm thinking reading the section on "Simple Design." If there is a trick to writing sustainable code -- and I'm not saying that there is -- this section just laid it out wonderfully, with my paraphrasing:
- Write code so that's appropriate to the folks who will be following behind you. Writing code that only can maintain isn't maintainable. Writing "guru code" only works for organzations that have them. Good Code isn't Moon in a Dewdrop, it should be Zen Mind, Beginners Mind.
- Write code that passes all the tests -- and have tests that "pass" when the code "fails as expected."
- Write code that communicates everything it needs to. That's much harder than it sounds because, as developers, we tend to assume a lot about what a person looking at the code knows about both the problem and technology domains. That's a problem for sustainable designs because the problem domain is much harder to grasp, and because of that, its much harder to document well. But frequently, mapping problem domain concepts to the code is only way to understand why somebody wrote what they did.
- Write the smallest amount of "decorative code" possible, ideally none. The book actually says "the smallest number of classes and methods" but I think it applies more generally. I'm bad at this because I tend to like to build code today anticipating future uses. But there's a different problem too: code that's written in a more complex way than the problem domain justifies. I recently got (rightfully) dinged in a code review for using an Interface pattern to a problem when its likely that we'll never really need more than just way to do the work at hand. That's a practice because it introduces unjustified complexity into understanding the code for the sake of making it fancier. Of course, if you don't push on things, you never learn them. Hard to decide how to balance that. On the database design side its very easy to go the extreme version of this with normalization. I can't tell you how many designs I've been part of that were either so overly normalized that they became nightmares to work with or so poorly normalized that they couldn't be sustained. Non-sustainable database designs create way more hard and expensive problems than they solve, of course. That said, code that seems decorative but actually helps the total appropriateness of the code is blessed indeed!
Now if more folks would just do that as opposed to "Just Glue It." Jeesh!
Speaking of TDD, Sam points us at TestDriven.net who offers a Studio add making it easier to actually use Nunit. Thanks!
I now resume my irrregular programming...