Long answer: it depends what you mean by re-engineering.
If we're talking about day-to-day refactoring, this should be done any time that you're writing code. It should become synonymous with coding, almost so you do it unconsciously. It should also be done as soon as possible after new code is written. The longer a piece of code lives, the more difficult it becomes to refactor.
For more serious re-engineering work, such as replacing a whole component (e.g. the persistence layer of an application) or even a full rewrite, things are more complicated.
Firstly I'd want to be sure that it's really in everybody's interest to take on such a large project. Is there long-term business value in making this change to the software, or are the developers just scratching an itch? You'll need buy-in from all the stakeholders if you want the re-engineering project to succeed. Otherwise you'll get halfway through, a 'more important project' will come along, and the project will be killed.
Second, you need to choose a good time to start. If there's a lull in development coming up, that's a perfect opportunity. Freeze all development and focus entirely on the re-engineering effort. If the project is being actively developed and this kind of freeze is not possible, you can start anytime you like, but you'll have to re-engineer against a moving target. In this case, I would suggest splitting the re-engineering into many tiny phases, re-integrating with the master branch after each phase, so your re-engineering branch never strays too far from reality.
In the case of a full rewrite, I would think long and hard before attempting it. I guarantee it will end up being a lot more work than you first imagine! I would only consider a full rewrite after you have thoroughly exhausted the avenue of refactoring, and after a 3rd-party solution has been ruled out. A complete paradigm shift (such as changing the implementation language or switching away from an obselete application framework) may also be a justification for rewriting.
posted 4 years ago
Thank you. In my team the paradigm shift is exactly what we embarked recently. We are migrating a
web application to a new technology.
In your experience can you share what risks that we have to be aware and mitigate in our project?
Or best practices and pittfalls, anything that can ease/smoothen our transition :-)
posted 4 years ago
When you're doing a full rewrite, the biggest potential pitfall to be aware of is lack of consensus about the spec. Rewrites usually fall into one of three categories:
A simple port to a new technology stack. You want the new system to work exactly the same as the old one (i.e. the existing implementation is the spec)
You're using the rewrite as an oppurtunity to clean up and update the spec (in which case you will need somebody to decide the new spec and document it)
As well as rewriting the existing functionality, you're also implementing some new features. This is quite common, because you need to give the business side some value in return for letting you rewrite a legacy system.
First of all you need to make sure everybody (devs, managers and any other stakeholders) are in agreement about which category you're in. Also make sure this fact is documented clearly. Otherwise you'll have endless arguments about every aspect of the spec, with some people saying it should emulate the existing system's behaviour while others point out that that behaviour can be improved upon.
You will also need to agree and document the scope of the project, in order to avoid feature creep. "Since we're taking the trouble to rewrite, we could also add a new feature here, and a new feature here, and ..." In the case of a simple porting project, feature creep is not usually a problem, but in the latter two cases, everybody needs to be clear on exactly what you're building, before you start the implementation. You don't need to decide the minute details up front; just a feature list is fine. Ideally you should also prepare a list of features that are OK to drop from the first release, in case the implementation takes longer than you expected.
"The road to hell is paved with good intentions." — old proverb
Joel Spolsky wrote something about software rewrites in his blog (http://www.joelonsoftware.com/articles/fog0000000069.html) and I agree with many of his points, having experienced them first-hand. It was my first project here in the US and it was a five-year, $50 million, 100+ person, total and complete failure. The project name even had "Rewrite" in it and ironically, the acronym was "CPR". It was, of course, DOA. Actually, it was DATS (Dead at the Scene).
I think one of the biggest pitfalls in a full software rewrite is more basic and insidious: hubris. Programmers will often look at poorly-written code and pronounce that they could do much better. They don't take into account that they have the benefit of hindsight. They also have the benefit of knowing more about what the software should do. But when it comes to delivering on the claim, they will more than likely make the same kind of mistakes the previous developers made.
Besides the things that Chris mentioned, there's one thing that often gets overlooked when a rewrite is in play: organizational structure.
Conway's Law states that software reflects the structure of the organization that designed and developed it (paraphrasing). In my experience, this is absolutely true. The key elements to successful software development are communication and collaboration. The quality and level of communication and collaboration that occurs is dictated largely by how the organization is structured. The other thing, too, is culture, which feeds into how well people communicate and collaborate.
Think about it: Most, if not all, problems in software, or anywhere for that matter, can be traced back to some kind of misunderstanding and failure to communicate. Whether those misunderstandings are between people or between people and machines — bugs are a form of misunderstanding — it doesn't make much difference: misunderstandings result in things not working the way they were intended to work.
I think Chris' more holistic view of re-engineering in this book is a good reminder of the other aspects of a project that must be made better if you're going to improve your software development process. However, the book seems to deal mainly with things that are more technical in nature. Section 1.4 of the book does talk about Legacy Culture but I don't know how much more detail and discussion is given to it later on in the book. If there are any holes in the book, this aspect may be one of them.
How do you address these kinds of issues? Well, I have found that while it does not guarantee success, Agile Software Development, when done properly, can help tremendously. I find that it's not so much the techniques involved when you do Agile development but rather the collective and individual mindsets and the cultural change that comes with it that make Agile so much better than traditional software development. It's not a silver bullet by any stretch of the imagination but it certainly is an effective tool in the right hands.