What is the best part about software development? Greenfield projects. You have none of the baggage of the bad decisions you made in the past, and you can create some code and see something new. That’s the attractiveness of this business.
What we get “paid for” is actually dealing with a lot of crap code, some written by us, the rest written by others. Ayende has a great quote, broken English and all:
There are always at least two people in any software project:
The developer who wrote the code.
The developer who read the code.
They are never the same person, even if just by temporal dissonance.
In other words, we will generally have a thought of “who wrote this crap”, and most of the time, it is our past self.
As tempting as it is, we cannot simply try to create new projects whenever we encounter difficulties or better ways of doing things. We would never get things done.
There are however instances that demand a new project. Here are a few that come to mind:
- Platform is not actively supported or vendor’s development has reached a sunset.
- Another major technology has supplanted the one your using in the marketplace, one that would reduce your codebase significantly.
- You have to re-read nearly the entire codebase to make any changes or you have limited tests, specs, documentation, etc. on a key application. This is a special case, one that’s not very popular and easily ignored when we get busy, but in this event, you want to capture as much of the knowledge from the developers now, this is your “project”.
- Your application is small (e.g. 1 developer, handful of function points), these are the perfect environments for learning new technologies, techniques, etc.
Any others come to mind? Let’s have them!
3 comments ↓
Two more cases: - The original codebase was crap. - The codebase needs a more extensible architecture (tied to the first one in some cases).
I recently rewrote a codebase because it was that bad. I usually say leave it if it works but there is a point where it’s more cost effective to rewrite a codebase rather than support it.
Joomla! and it’s 1.5 release is an example of the 2nd point.
I agree when the codebase is crap, although that can quickly get muddy. I generally think all codebases are crap, save for my flavor of the day.
More extensible architecture? I’d like to hear more detail before I weigh in. Currently, I’d disagree, as I stated above:
What kinds of things did you have in mind?
OK, I agree that all codebases are crap. But, depending on the context of the crap there is a time to rewrite it so it’s less crappie. The crappiness level to rewrite for me is when it’s cost effective to your business objectives. For example, if your system requires a lot of support to teach users how to use it because it’s not intuitive you might rewrite it (or that part) because the overall cost will be less in the end and it will be easier for users.
Also, making a more extensible architecture in and of itself is not a reason to rewrite. Some things just don’t need that and adding it can go against the business goals. If you make something more extensible but never use it though you get a performance hit that’s no good.
Now, you should never rewrite just to rewrite. For example, if you have crap code that works beautifully but you can’t stand to look at it you should leave it be. It may be ugly but it works. Rewriting code means dealing with bugs and all kinds of other goodies. The decision to do that shouldn’t happen lightly. It can hurt like a truck running over your foot.
Leave a Comment