Code Sucks

Most code sucks. Mine included... especially mine... but other people's too. Despite the best of intentions and planning and playing with paper sketches and squiggly lines, all code eventually turns into an impenetrable mess.

You can follow all the rules about writing code and organizing modules and whatnot, but you end up in the same place. The problem is that we don't know the rules to writing software yet. The rules we do have a contradictory. We work with people that don't know the rules and/or don't know about them.

It drives me insane.

Sometimes you can fix parts of the code. Line by line, class by class, you can refactor and test as you go. Or, at least, that's what I thought. Sometimes there's just too much inertia. Your best code doesn't work in the presence of the existing code. Sometimes the code, the project, and the team are just too far gone.

It's a sinking ship... and there's no honor in going down with her. Man the lifeboats and wait to get picked up by another ship.

What's in your object?

In the ThoughtWorks Anthology, there's an essay by Jeff Bay called Object Calisthenics. Briefly, the essay lays out a set of rules for designing classes that are rather strict and quite different from what you'd normally use to guide your programming. If you do a quick Google, you'll see that this essay has received quite a bit of criticism in the blogosphere. Most people seem to say that the rules are too strict and just get in the way.

If you haven't read the essay, there's an overview here.

I'm applying these rules as much as I can in my day to day development, and I've noticed a few things. First, it's not kind toward legacy code bases. It is especially unkind toward WPF applications. WPF is built almost entirely on .NET properties and practically begs you to break encapsulation. Yuck... but I blame WPF rather than these rules.

Next, it's turned my code inside out. I'm used to grabbing a few objects, getting some data out of them, doing something to that data, and then passing that data to some other method. Usually this is so I can then return a new value. Since I'm not doing gets anymore, I have to send commands to those objects and then let them do some computation on behalf of the caller. It kinda reminds me of the message passing style you do in Erlang.

So what's this gotten me? For one, unit testing is easier. If you use get, you end up with an object that you then have to verify. This object will have state of its own which will likely have to be verified. This isn't a unit test anymore. It's an integration test. Instead, by sending messages, especially with mocks as parameters, you only have one layer of code to test.

Also, Dependency Injection become much more natural. But that's a topic for another post.