Second Drafts

When you work on a piece of software, do you ever find yourself wishing you could rewrite it? I know I do. In fact, sometimes for fun I will take little pieces of code and attempt a rewrite. That rewrite may never actually be pushed into the final product but it helps me understand the problem and how the code was solving it. And if my rewrite isn’t better, it’s an opportunity to ask why and improve my own practice.

My experience in industry, however, is that most people don’t do this. I think there are a few reasons:

• Risk of introducing a bug. Anytime you touch code, you have a risk of introducing a bug. Depending on the situation, those bugs can be very subtle. People avoid changing code because they don’t want to risk introducing a defect. If you don’t submit your rewrite though, there is obviously no risk.
• Ownership of a domain. I’ve seen people avoid changing code because they feel like someone else owns it. That can be a valid reason. The other person, or other team, that maintains the code understands the use cases and users better than you. In my experience, most people are reasonable and that other team or other person is often happy to explain the rationale behind their work. I find it better to at least file a bug report or pull request and see how it goes.
• Priorities. Businesses want to deliver shiny new things to their customers. Also, software engineers are usually more interested in building new features rather than improving existing ones. For both these reasons, fixing old things isn’t always top priority. That is fine most of the time. Customers want new things and engineers are happy to build them. It’s a good habit to ask about old broken things because sometimes that is the source of customer pain.
• Lack of craftsmanship. Like any job, some people just don’t care about quality. They are there to earn a paycheck or hang out with people with similar interests. Lots of people do care about their work, of course, but some want to do the minimum and move on.

I think much of this could be summed up with the phrase: “If it ain’t broke then don’t fix it.” That phrase is often the right approach but not always. Sometimes things are actually broken so keep your eyes open.

There’s a famous Joel Spolsky article, Things You Should Never Do: Part I, which argues that Netscape’s attempt to rewrite Navigator from scratch caused the whole company to fail. Joel makes a lot of good points and I’ve watched from the inside as companies I’ve worked for spent years trying to rewrite whole big systems. They spend years building something equivalent to their legacy system meanwhile the legacy system has added more features and now the rewrite needs to adapt and catch up. Those companies blow past initial estimates hoping it will eventually pay off. Rewriting a whole system is hard. I’m not really talking about a whole rewrite here, just poking around at little bits and pieces of software and sometimes those can be rewritten successfully. Joel makes the same point:

If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That’s fine. You may want to refactor a class to make it easier to use. That’s fine, too. But throwing away the whole program is a dangerous folly…

First Draft or Production Ready?

My kids came home from school the other day talking about their first draft. They’ve been working on a drawing assignment and the teacher expects them to create a rough draft and then create a “good” copy. It struck me that artists do this all the time. Writers have first drafts and film makers shoot with prototypes or stand-ins and engineers build prototypes and mockups to test their ideas and materials too. Why do software engineers think they can create the correct solution on their first try? Why don’t we expect to rewrite our code?

Okay this is not totally accurate - we do build prototypes. When I go exploring a new problem or idea I’ll often write code with an expectation to throw it away. I wrote prototype code in JScript to learn about active directory. I write python scripts all the time to process some data or try out an algorithm. There is something different about production code though or the idea that what I’m working on will go into production.

As soon as I start thinking my prototype will go into production I write it differently. I’m careful. I question my decisions and choices. I research dependencies carefully. I try to anticipate future requirements. I write unit tests to make sure the code is doing what I expect. All of these things are good but they slow me down. They prevent me from getting to the real value: a working solution.

Punchline

Now I’ve got two approaches for writing software:

1. The first draft approach where I write code and expect to throw it away. This sometimes means that my prototype code goes into production and I expect edge cases to come up and cause bugs. This is okay because the code is lean and easy to replace - or hopefully easy to replace.
2. The production ready approach where I spend hours writing unit tests and carefully choosing dependencies and patterns and practices. In the end, I have software that took a while to write but I hope to rely on it for years to come.

Which approach is better?

My guess is that, like most things in life, neither approach is correct all the time. Probably the right answer is somewhere in between or perhaps there is a third way. It will depend on circumstances and details and the individual. I think I have a tendency to naturally follow the production ready approach and I could benefit from applying, or at least considering, the first draft approach. I know I’ve worked with people who seem to naturally apply the first draft approach. I’ve sometimes had the pleasure of cleaning up those messes - and I do mean pleasure. Rewriting a messy piece of software into something tidy can be really rewarding.

Maybe my takeaway is to remember that both approaches have merits and I need to practice both.