index.md 11KB
title: To Rewrite or Not, That is The Question
url: http://blog.aelogica.com/development/rewrite-not-question/
hash_url: effe69ce88
A Million Dollar Problem
You have a successful software product or web application that took years to produce and debug. Now you want to pursue new opportunities and make major changes, perhaps refresh the user interface to keep up with changing trends and competition but your development velocity has slowed to a crawl.
You hear gripes from your developers about the state of your code. Changes are difficult and error-prone. Your developers have begun to advocate a for a Big Rewrite or perhaps soft-pedalling the issue, a mere “overhaul.”
This is a common scenario for growing businesses and it presents a very tricky and potentially expensive problem. Sometimes it even presents a lurking existential threat to the business.
At ÆLOGICA and in my prior freelance work, I have assisted or led customers to re-write or “re-skin” as well as simply maintain, enhance and refactor large existing Ruby on Rails web applications. We have tried different approaches and I have a number of useful observations to share about the process.
As David Heinemeier Hansson, creator of Ruby on Rails and founder of Basecamp, recently advocated in his post, The Big Rewrite, revisited, sometimes the right answer is to do the dreaded Big Rewrite, but with the caveat that how you treat users in the process can make all the difference.
What makes people want to abandon a working system and start fresh? What are the options? Is there a less risky approach?
Naturally every case requires a close examination of the business objectives and strategic direction, as well the code base, financial resources, team size and the history of development effort and velocity.
Calculate the Maintenance Burden
Maintenance of a large code base or system will eventually grow to consume a majority of a development team’s bandwidth — especially if team size is kept constant. This leaves a shrinking portion to devote to new features and changes to advance the objectives of the business. As this situation persists and worsens, management becomes frustrated with progress and team morale suffers.
Retention of key talent often presents a substantial unexpected risk to the business. Competitors may pull ahead while you are stuck trying to backfill departures and onboard new team members. Something must be done, but what? Product managers, engineering managers and executives are right to tread cautiously.
I use a rule of thumb that for every X developer-years of new feature development, 20% of X will be spent in each subsequent year on maintenance of that previous effort. Everything you do imposes an ongoing cost stretching to the end of system life. That is reality, regardless of whether you employ top talent or follow best-practices.
Let’s look at what this looks like over 5 years. For purposes of simplicity, we will assume we do no “maintenance” in the first year.
Here we assume a constant team size of say 4 developers for the entire 5 years. By Year 4, our productivity from the point of view of the business has halved. By Year 5, we are spending the majority of our time just keeping the thing running — treading water. This is right about the time the business may wish to make a strategic shift, branch out into new markets or exploit new opportunities.
Often team size grows and shrinks over the course of the system lifetime. Perhaps management engages contractors or an outside firm or agency to meet targets early on. If in Year 2 and 3, additional developers were added to increase velocity, and several developers departed or the engagement ended by Years 4 and 5, 90% or more of the team’s bandwidth in Year 5 could easily be devoted to Maintenance. Forward progress would be almost nil. Turnover and other factors could further limit productivity.
Of course your mileage may vary. Your number might not be exactly 20%. Very talented and senior developers can avoid many of the pitfalls that bring about this painful state too early. Less-skilled developers or careless outsourcing to less competent agencies can accelerate the problem such that by Year 2 or 3, you are in deep trouble already. In either case, the growing maintenance burden is inevitable and so will be the eventual call to do a Big Rewrite.
If you find yourself in this situation, and you have managed to retain ambitious and talented-enough developers, especially if they are not the ones you started with, they will likely want to throw out the whole thing and start over.
When Product comes along and asks for a major overhaul or a substantial new feature set, a new UI or all three, the developers will often use this as an opportunity to push for the Big Rewrite. Occasionally they may make a compelling enough argument. Often the real argument is that they will leave if the company does not pursue a rewrite. Now it may feel like you are being held for ransom by your own team!
This is often a million dollar or multi-million dollar problem. The wrong move can sink your company and put you out of business or merely close off precious opportunities for substantial growth.
Let’s pause there between Scylla and Charybdis for a moment.
Why Do We Want to Do This?
There can be good reasons. Are they good enough?
After five or more years, perhaps you have a much keener understanding of your customer base and product than you did at the outset. If senior technical people agree that a different architecture would much better serve your needs, it can make sense. Proceed with extreme caution. Perhaps it would be better to start a new product along side the existing one to address the new opportunities. As DHH suggests in the article linked above, you might want to plan to run your new product version in parallel with the old one indefinitely and not force customers to upgrade.
Perhaps your developers argue that the state of the code is a mess and it takes too long to make changes. When your team makes changes, they introduce too many bugs. If this is the substance of the argument for a rewrite but at the same time no major architectural change is proposed, rewriting may not be the best option. Your team may simply be in over their head.
You might want to call in a senior consultant to evaluate refactoring the most painful parts of the system and to chart a path to sustainability. Even if expensive, this can be much cheaper than a rewrite and lower-risk.
Another common argument, although rarely stated this way, is that some new programming language or stack is the new hotness and would better serve your needs than your current obsolete stuff. The not-so-hidden agenda here is that your team wants to pad their resume with highly marketable skills and look for higher-paying jobs. They are not wrong to want this. Why shouldn’t they? You may even need to accommodate them. Be careful though. If the project goes poorly or you mismanage, you could lose half your team before you go live. The developers will all be learning on the job, doing their first big system in the new language or stack and will make neophyte mistakes as they go.
It is possible to succeed at switching languages and frameworks. It may even be justified if your current system really is so old and obsolete that you cannot find people with the skills to work on it. Obtain outside advice on the proposed solution and consider the needs of your staff for professional growth as well as your ability to attract and retain developers experienced in the new platform. Try to hire a couple developers who already have experience in the new platform who can help prevent your team from making mistakes as they learn. If you are unable to hire experienced developers in the new technology, consider it a sign that you won’t be able to hire them in the future and decline the platform switch or look for another better option.
How Do You Staff for a Rewrite?
In my experience, a total system rewrite for a large web application that has more than a couple years of active, full-time development and production use can take anywhere from 6 months on the very lowest end to more than 2 years. The more work involved, the bigger the team required. Two to four developers is generally adequate, with perhaps a maximum of six. Larger teams introduce the need for greater management and planning and may actually take longer to ship. Six experienced developers may cost almost $1 Million per year in the United States. Two developers for six months will cost about $150-200k depending on whether they are employees or contractors, etc. Any way you cut it, this is not going to be cheap.
If you have a team that is talented enough and highly motivated to do a rewrite, and they have convinced you that it is the right thing to do for the long term interest of the business, you will still have the problem of how to maintain and enhance the existing application while they run off for potentially a couple YEARS to complete said big rewrite. Keep in mind, it always takes longer than you expect and you will not likely achieve feature parity until well after launch. Everyone internally will want in on the project. Few will be happy to maintain the old system while everyone else is having fun on the new system.
I view maintenance, enhancement and the responsible, long-term-care of existing systems to require a high degree of professionalism and skill. Often it even requires higher skill and discipline than writing new code. This type of work is for mature professional developers. If you are proceeding with a rewrite, you need your most experienced developers on your new system to make sure it really will be as good as they claim. You may have difficulty hiring developers with the skills to maintain your existing application as this type of work is often viewed as less desirable.
Consider augmenting your maintenance team with outside or offshore developers.
At ÆLOGICA, we specialize in providing teams of skilled Ruby on Rails developers for long term engagements. We provide quality developer bandwidth like a utility for clients who need to augment their internal capabilities.
Whether you are exploring a rewrite, overhaul, re-skin or other major effort, if you need more talent and capability than you can source locally, or if you just want some outside advice on how to address these concerns, please reach out to me: steve@aelogica.com