Someone said to me the other day. “I love that code. It’s so structured”. This is the first time anyone had ever admitted to me that they could indeed love code. Before I lifted the receiver to call the men in white coats I tried to absorb what he’d said. What he really meant, I suspect, is that he appreciated the code. But the more I thought about it the more I thought that we do in fact enter into relationships with the things we write.
This is further evidence, I guess that writing software is a creative process like painting a picture or designing a building. It becomes emotional. I suspect I’m far from alone when I say that I’ve spent a significant proportion of my career in an emotional tug-of-war with the programs I’m working on or have written myself. They have a sort-of-life all their own and usually I’m the Doctor Kildare keeping them alive. I haven’t lost a patient yet. But the most curious part of this form of creation, at least to outsiders, is that it has no permanence and the structure that my friend so admired is almost entirely abstract.
This impermanence makes the code we write invisible to the people that see what the code does. They have no knowledge and probably little understanding of what it took to make that program. When those people are the ones making the decisions then Houston we have a problem.
But there’s clearly good reason to be in love with your code. The more you love it the better chance it has of doing its job, working most of the time and failing rarely. But the best part of all is that by expending that little extra effort you made something that someone else can not only appreciate and understand but can modify themselves.
The stark reality of writing code that will get used for a purpose (and why would you do anything else?), is it will very soon need to be changed. If that code is successful it will only be a short matter of time before a new feature is added or, in the extreme, that code is used for something else entirely other than what it was designed for. I’ve seen that happen on two very large projects (>100,000 lines of code) and the fact that it could be done at all is evidence that the original code was well loved. In fact it would be difficult, I suspect for that code to exist at all if wasn’t loved. But once the purpose of the software is changed all bets are probably off (and the subject of another post!).
Consider then what happens when we don’t love the code we write. You don’t love it because you built it to throw-away or you built it under pressure always meaning to come back and fix up later. I’d be the first to admit that I’ve done this. There’s probably a few repercussions from being in this position. The chances are that the user that is on the receiving end of this unloved creation will get frustrated with it. That frustration will find it’s way back to you. Beware.
Worse is when you end up being the one frustrated with it and unable, for whatever reason, to change it. It’s like being Dr Frankenstein and watching your monster rip up the town whilst you sit in your chair and scratch your head for ways to bring it under control. Perhaps if you hadn’t sewed the monster’s head on backwards you wouldn’t be in this position? Well you’d better break out the sewing needles friend. You’re going to need them.