That’s a brave admission in our industry, but I am willing to bet that even the best of best write bad code now and then. I bring this topic up for several reasons.
For one thing, honesty is the best policy. I just don’t think we see enough of it. In the blogosphere, I rarely find posts that deal with “struggle”. I think that’s a shame, too. People deal with their struggles in private and post from a position of authority in public after the fact. But, you know, I’d really like to read about the struggle part, because I sure have a lot of them. I want to read about how some guy totally sucked at something or got his ass kicked and then read about the steps he took to not suck so much…and not get his ass kicked. To me, that is not only real, but valuable. I have tried to do some of that in my own blog.
Second, I recall a recent incident that occurred when I looked at some code written by a junior colleague of mine. He looked at me and said “It’s not that bad, is it?” I thought it interesting he would ask me that. He suspected it was bad, but couldn’t tell me why, which is pretty much the point of the post.
I think it’s important to know when we are writing “bad” code, or to put it more sensitively, less than optimal code. I do it all the time. When I am rolling full speed on a large project, I probably do it every day. However, I do have some saving graces in this regard.
Most of the time, I know why the code is bad. I can usually tell when I am violating things like OCP, SRP, DRY, and so forth. Or more simply put, I usually know when I am doing something that is going to be hard to understand, make the code less flexible, and degrade maintainability. But I do it anyway. I gotta get to green!
The good news is that code is not stone. I’ve said it once, I’ll say it a thousand more times. Code is the most malleable substance on Earth. Alchemically speaking, you can make anything from anything when you have some code. And, if you have some unit tests to back it up, you can take this concept to a whole new level.
So, I make refactoring an intimate part of my short-term development cycle. It’s not something reserved for later. Refactoring is now. I seem to have a never ending litany of questions going through my mind: How can I write this once? How can I say this better? Where does this code really go? Is this a concept that needs to be more explicitly expressed? Would the guy maintaining this want to kill me? This is an inner dialog I have worked hard to develop.
As a result, my bad code usually gets scrubbed out shortly after it is written. But sometimes not. No, I really don’t like admitting that. But the truth is, more often than not, solutions just don’t readily present themselves to me. I have to seek out the truth and it takes considerable effort sometimes. Typically, my first effort is not going to be ideal. Just knowing this seems to be half the battle. For me, finding simplicity takes effort and it is one of the most difficult things I have ever done. I see the process of writing good code to be an iterative process with many considerations. I might even look at it as figuring out how to not write bad code.