It's My Fault

There's a natural human tendency for people to want to assign blame when something goes awry. In particular, when assigned to messy code, programmers tend to blame management for not giving them the time to clean it up before being forced to work with it. At least, I am guilty of this.

But thinking about it seriously, I came to a (seemingly) obvious conclusion. I am wrong to assign blame to management. This not to say that their feature demands are reasonable given the current state of the code base. I am wrong because the quality of the code base is my responsibility. It does not matter that I was not the one to create the mess in the first place... it is my domain, and hence, my responsibility.

I should not 'ask for time' to clean up the code before proceeding on the new feature requests. The messy code is a direct hindrance to me completing my job and as such, it is my responsibility to remove that hindrance before proceeding. In essence, I don't ask for 'permission' or 'time' to clean up the code. I clean up the code before I start adding to it. Period.

That's not to say that refactoring code comes in the way of bug-fixing and feature additions. That's not to say I am some renegade who refuses to conform to the will of management. It's just the realization that management does not care about the quality of the code - they care about removal of bugs and enhancements to the system. How those things are accomplished is my job. Trying to convince them of the best way to do my job is foolish on my part, especially since they cannot appreciate the importance of code quality when it comes to modification. That's no weakness on their part... it's not their job to appreciate code quality. It's mine because I know the effect that the lack of said quality can have on the ability to do my job.

That's not to say that I plan to go guns-blazing and rewrite anything that looks sloppy. But, whenever tasked with a maintenance issue, my first step will quietly but assuredly be to clean up that area before I begin handling that issue.

It seems pretty obvious when stated like that, doesn't it? So where's the epiphany?

There's none, really - except for the sad realisation that I was taking on a battle with management over code quality that served no purpose except to handicap and frustrate me. At least I have learned my lesson, which will help me in the future.

Operational Complexity

I was reading a blog post by Paul Homer discussing complexity and containing it via encapsulation.

One important part that may be overlooked in his discussion is talking about the different types of complexity: design, implementation and operation.

The complexities of design, implementation and operation are very different from each other. I've seen a few large projects that have managed to contain the implementation complexity, only to lose it all by allowing the operational complexity to get out of hand. Each part in the process requires its own understanding to control its own special complexity. Each part has its own way of encapsulating the details.

We, as programmers, can understand design complexity - our job constantly puts use in battle against it, trying to keep it under control. Similarly, implementation complexity is usually tied to code complexity, and hence we recognise the risks and dangers of ignoring such complexity, and (hopefully), move to remove it.

However, I believe operational complexity to be completely ignored as a source of problems, which can be just as dangerous.

From my own personal experience, on joining a new programming team, and getting help from the version control manager in getting set up with the version control system, I was told "NOT TO WORK OUT OF THE WORKING DIRECTORY". That really put me on pause.
Don't work out of the working directory? Isn't that why they call it a working directory? Because you work out of it?

No, she told me. You might accidentally retrieve something from the version control system and overwrite, and hence lose what work you are currently doing.

Then, she proceeded to show me a round-about procedure of interacting with the version control system without actually working out of the working directory. (This 'procedure' involved copying stuff from one place to another, making your changes and copying them back). I was skeptical, not wanting to rock the boat, I fell inline. After all, things were always done that way.

However, after a few months of jumping through hoops just to check in my changes and losing some of those changes along the way, I had enough. The operational complexity was making life too difficult.

It turns out that the risk of losing code changes while working out of the working directory was real... because the settings in the version control client were off.

Now, a check-in, something that used to be a 10 minute affair of copy-pasting and diff-ing a number of files, is now a 20 second, stress-free affair, as it should be.