Not that long ago a very wise coworker said this in a meeting:
The biggest lie in software is, “We’ll clean that code up later.”
Insightful. I admit, I’ve said this before, and, like others, I haven’t followed through. I suspect this happens often because, being busy developers, if a section of code works there seems to be no immediate value in refactoring it. It works, we have other things to do, and we move on…
I was thinking about the “biggest lie in software” again recently. This time the problem was a little different, but still something that I have come across numerous times.
I can’t recall the number of times I’ve been asked to put together a prototype or a very simple application for a temporary purpose only to find that the prototype/temporary application somehow morphs into a “real” application. (By “real,” I mean, people start using it daily in an ongoing manner that was never intended.)
This happened to me again somewhat recently, and I was very surprised when I was asked if there are a requirements document for the application (which I had spent all of a half a day putting together).
What’s the solution here? I’m not sure. Things move fast and everyone has needs to be met. Sometimes, even in the year 2011, people don’t really understand what software can do for them, so when they see a simple prototype or temporary application, they are excited about the increase in productivity that it can offer and they run with it.
I have a few more thoughts on this subject, but for now I’ll end with a list.
- Set expectations clearly. If an application is a prototype or throwaway, make it very well-known that this is the case.
- This is a little more difficult: Never write code with the assumption that it will be thrown away after demonstrable use or serving its temporary purpose. For example, I’ve created a few GUI applications that grow into something bigger. I used no real patterns or MVC layout–I simply threw something together using AWT and Swing in NetBeans. Its full of global variables and improper forward and backward class access to methods and values that should probably be private. If any real software developer were to look at the code I would probably blush.
- To pull off #2, write your own code with reuse in mind. That temporary application is likely to be useful when implementing our full-blow project.
I’m writing these rules as if I follow them myself. To be honest, I don’t always do this. Sometimes there are a number of groups tugging developers in different directions, and its difficult engineer something both appropriately and quickly all at once. That said, we shouldn’t be surprised when that throwaway application we whipped up one afternoon a few weeks ago takes on a life far beyond anything we ever anticipated.