Robert Martin has written another article. There is a lot of truth in what he’s said in it. I like how he cuts through to reality.
I am about to dig into FlexScheduler again to add some features. I’ve written a few other Flex apps since then and I’d love to start over on the Scheduler, but it’s not realistic. I decided yesterday that was going to try to do what the author says to do in this article. A good change for me.
Wow, and ouch. I’m the guy who dearly wants green fields, but the comments emphasize the need to consider business needs, which I’m gradually learning makes significantly better consultants (which we want to be).
I’m not sure this applies to picking up the pieces from other developers, however…well, maybe it does, but I’d much rather repair something I made badly myself than something someone else made badly.
A good article for us, I hope to see more comments here from you guys.
I definitely tend to agree with what he is saying, as I understand it. There are reasons that software grows and the little quirks and problem solutions that come in along the way are what make it meet business needs.
It’s true that sometimes things are a mess, but generally I think that it is more developer optimism or wish-dreaming to think that if we just had a clean slate you could do it dramatically faster. Or if we did it in X technology it would be dramatically faster. As Fred Brooks says in Mythical Man Month, there are no silver bullets.
I think we may be in a slightly different scenario than the story he describes. We, as outsider developers, will always need some time to familiarize ourselves with not only the application but also the code. In a rewrite scenario, we only need to understand the application and “the way it should work.” In a refactor and maintain case, we’d need to understand what the application is supposed to do from the user’s perspective, but also what it does internally. This can be a place for huge variation, heavily dependent on the cleanliness of the code and our familiarity with the framework/language they chose.
However, it’s likely that the time it’d take us to understand the app enough to make whatever changes the client is asking us to do is less than us rewriting the whole app to the new specifications with all the existing bells, whistles, and accompanying bugs. Consider our experience with a recent app and a client custom CMS. We made changes and improvements to an existing system in less time than it’d probably take to rewrite it. I know I’d have loved to re-write the CMS because the existing one is a bit clunky and oddly designed in places, but it wouldn’t make sense to rebuild the entire thing just so I could add a new content section.
And don’t forget about having to migrate the old data! When considering the learning curve for existing code to maintain a system versus a green field rewrite, remember that you’ll either have to dig into the old mess to migrate the existing data or stick with the old and messy data model that likely cause much of the current problem. (Unless of course your client is willing to give up all their historical data…)
I would mostly agree with Martin, especially for large systems that have evolved over a long period of time. There’s just a lot of knowledge that gets embedded into code that can’t necessarily get teased back out into specs for a completely new system. I agree that the right approach is not a wholesale re-write, but a continual improvement/refactoring of smaller sections of code.
I don’t think that the answer for when to rewrite is never… but almost always. I think the decision to rewrite depends on the size of the project and, as Jeff mentioned, if data migration is necessary. For example, for small scale coding projects (less than $20k?) with well defined requirements and no data migration, re-writing could be a better option, especially if the intent is to it build out eventually.
It is an ongoing temptation for us devs, though. Looking at some code that we have taken over from other developers makes me want to start over, but, practically speaking, I think we’ve been doing fine putting together solutions for them based on their existing code.