That's what one should do, but I generally see the incentives setup all wrong.
The most common scenario is that the fresh young smart ** hoodwinks the boss into giving them 1-2 years and 2 subordinates to help them do the rewrite in isolation. They come off all support rotas and have no responsibility for BAU operation of the old codebase. The old codebase is left with usually a same or larger team maintaining and still adding new features.
The other way I've seen this done is that senior management really wants the rewrite, shops around for a candidate internal or internal who promises to do it.. and then basically same setup as above.
Setting up an explicit "good" and "bad" team creates awful vibes, the "good" team never delivers and starts exiting as accountability starts to creep in.
Meanwhile the "bad" team hemorrhages staff continuously from the burn out of maintaining the old thing with less people while also being told your job has an expiration date.
The big rewrite works - but only if you have a team you can trust.
You need a new team of seniors to pair with the current team, promise a promotion to the current team at the end of the task.
Committing to an iterative approach is what I do when I don't have enough authority/ political tokens and I can't afford a rewrite.
Over time it gets less and less priority from the business and you end up with half a codebase being crap and half codebase being ok and maintaining stuff is even harder.
A project is done when no one is willing to work on it anymore.
We are all employees, not owners. Decisions that look good on paper won't stop people from finding a new job if the consequences of that decision are more than you want to deal with. And won't the new person want to rewrite it anyway? Now we have a rewrite being done by a person who has no idea why all the weird code is so weird.
So the trick isn't rewrite or no rewrite, the trick is how do we make the rewrite give us things we couldn't have without it. Employee retention is important but as you say that's not enough for the board or the users.
And rewriting in phases avoids the worst aspects of rewrites, which are sometimes undertaken in bad faith (intentionally on unintentionally). Some groups I've seen seem to enjoy the fact that you get to write a lot of code without thinking too hard, and management doesn't pester you about deadlines too hard for the first six months. Those are not good reasons for a rewrite, and they usually end pretty badly. But by then the developers have been at the company long enough that the duration looks good on their resume.
Old developers have left. New ones come in. The systems the old devs built suck, so the new team convinces management to do a rewrite. The new devs don’t really understand the problems encountered by the old ones so they repeat all the same mistakes. New system, same problems.
The lesson we’re supposed to take away “no one should ever do full rewrites”. It’s a stretch, but IMO the proper takeaway should be 1) really understand the old system and 2) have a very good reason before doing full rewrites.
The problem with people new to the company starting a rewrite from scratch is that they often are poorly informed on why things were the way they were before. If you start big, you can have bad outcomes where the new system might be objectively worse than the old one... but you are stuck trying to get the new thing out for the next 5 years because too many people sunk too much political capital into it.
As an example, I worked at an ad-tech startup that swapped it's tech team out when it had ~100 million in revenue (via acqui-hire shenanigans). The new tech team immediately committed to rewriting the code base into ruby micro-services and were struck by strange old tech decisions like "why does our tracking pixel return a purple image?". The team went so far as to stop anyone from committing to the main service for several years in a vain attempt to speed up the rewrite/architecture migration.
These refactors inevitably failed to produce a meaningful impact to revenue, as a matter of fact the company's revenue had begun to decline. The company eventually did another house cleaning on the tech team and had some minor future successes - but this whole adventure effectively cost their entire Series D round along with 3 years of product development.
That doesn't sound like an 'or' to me. That sounds like a 'why'.
A rewrite also means no new features for a very long time. And my very cynical view is that people asking for a rewrite are motivated by the peace and quiet that happens during the first six months of the rewrite. In a world where people leave after 3 years and get a pass for their first few months that represents a pretty large fraction of their tenure.
But it's a bit like rehab. You've decided to start over with a new set of habits and hope it sticks. But like rehab or new year's resolutions, the relapse rate is high.
My current take is that there is a paradox here. The teams that deserve a rewrite usually don't need a rewrite. There's a high degree of overlap between being capable of fixing your broken crap properly and being able to refactor to a better system.
The only rewrites I've seen work look like the Ship of Theseus. As far as management is concerned it's not a new system. But the old developers can barely recognize the code.
far too often I have found rewrites, which in many cases involve moving to new hardware and possibly OS, tend to drag on because those involved do not know all the touch points of the current systems and also fail to properly count the investment other teams have in making connections to the original systems.
I have even seen them done to bypass a management/development team that was in disfavor with the company leadership. In effect, put together a new platform with new leadership.
Rewrites are also sometimes very good for your career. A friend working at Google for about ~1.5 years said a new Sr. Director of Engineering joined and their first decision was to rewrite the project, and it would take 2 years.
So now the Director has job security for about 2 years, gets the big launch near a promotion cycle they have a small chance of being considered for promo, and gets to blame the predecessor for all the problems.
I'd call that a continuous rewrite, which is also the strategy that worked best for me. If you're not willing to make these investments as you go, you may well end up in a full-rewrite-or-die situation, I suppose. Comes down to how aggressively management prioritises short term results. I personally have never worked on a code base that far gone, but I can imagine they're out there.
Sure you get to re-write them, and you are a fool not to. However the rewrite needs to be spread out over 30 years. Note that after 10 years your replacement needs to be rewritten as well.
The trick is figuring out what this the priority. There is some 40 year old software that mostly work: it runs fast enough; it doesn't have many bugs; it doesn't follow best practices that the software world has discovered since; and it rarely needs new features. This code needs to be rewritten but the value just isn't there. There is other code that at only 5 years old needs to be rewritten: it is full of bugs, new features have been tacked onto an architecture that wasn't designed to support it - this software needs to have a large budget given to fixing it in the long run this will save a lot of money. Most projects are somewhere in between, you should give the team a little extra time/budget so that they can keep the maintenance up to do and it will never get much worse.
Rewriting is rarely a good business decision. Companies have already invested time and money and changed their internal processes. I maintain and fix what they have. If they decide to replace it I am usually the first developer they offer the job to.
Would a rewrite necessarily benefit the business? Can you make a strong case for that?
If not, start writing tests, try small incremental refactorings, ask your manager to hire more people, maybe someone not as qualified as you but that can take on some more of the unpleasant activities. Maybe you can negotiate some 20% time? Use that time to build tooling to help you do your job better. Share it with the world. Management won't give you these liberties? Find another job. And ask the next company to show you their code metrics before you seal the deal.
So you're the new guy that's been assigned to this project...possibly at the request of the current developer who desperately needs help...possibly because it's the project that existing staff don't want to work on...possibly to learn the project so the current developer can be moved to other projects.
Every software company has these projects and many developers have been in your position. As long as the software is still functional and is profitable then management don't care how bad things are under the hood (try explaining it to someone who only sees a working/functional UI). The fact a new resource (you) has been assigned suggests it's still a valuable project.
Unless management are the ones giving the go-ahead on the rewrite then I wouldn't bother. Rewrites are very risky, time-consuming and make no money for the company. However long you think it will take...double it. You're a mid-level developer, a rewrite needs to be planned and led by an experienced senior developer.
Your best bet might be patience...try ride it out and hopefully be moved onto other projects. In the meantime you get experience. It's how you handle the adversity that could prove more valuable.
Sensible for who? Companies may try to estimate costs of maintenance vs rewrite, but individuals need to make the final call and for them the benefits usually go the other way.
Maintaining some existing project is going to get you nothing if you do it right and will bring you problems if it breaks despite your best efforts. Rewriting an existing system in a new tech stack counts as exciting innovative work for promotion purposes, or at least prepares your CV for your next job hop. With salary bumps between levels being what they are in software, I'm not surprised people choose the more lucrative option.
At work we're in the position where three of our main competitors are struggling bad after all trying to rewrite their software. Good for us, we've captured a number of their clients due to this.
We've instead focused replacing parts of the program over time. If we touch some old code that works but needs to be extended for a new feature, we usually rewrite it and bring it up to date as part of implementing that feature. Other times it might be too sensitive and we just modify a small piece of the old code and let it chug along like it has done for over 15 years.
Instead of spending time rewriting the whole shebang we can deliver features, alternatively not having a second team reimplementing everything avoids a huge financial burden.
I've seen smart people fall into the following trap:
1. Previous developers did X and X is bad, therefore, their code needs to be rewritten without doing X.
2. Oh crap - turns out, the new code has all these requirements to match the old code's functionality in ways we didn't expect (letters A-W).
3. Okay, so we're doing Y and Z in the rewrite, knowing it's pretty bad, because we didn't know we'd have to do A-W and now we're short on time. Oh, and parts of the code still do X.
Now, wait a year for one third of the team to leave because they're rushed, overworked, burnt out, going in a different direction... and another third to get laid off because the project went way over time and budget...
4. Previous developers did X, Y, and Z, and X, Y, and Z are bad, therefore, their code must be rewritten...
I have been involved in a successful rewrite. It cost billions of dollars and many years when the code wasn't working so the old system was still in use. We also ended up bringing over some old code directly just to get something - anything - functional at all. For many years my boss kept the old version running on his desk because when there was a question that old system was the requirements.
Today we only have to maintain the new system (the old is no longer sold/supported), and the code is a lot better than the old one. However I suspect we could have refactored the old system in place for less time/money and been shipping all the time. Now we have a new system and it works great - but we already have had to do significant refactors because some new requirement came along that didn't fit our nice architecture.
I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better.
If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL there's no incentive to help the company succeed. Especially with non-technical management, the best thing to do for ICs is often to aggressively rewrite (in the language that's trendy right now and that better companies use) and get promoted by showing off a significant output. Then jump to a better company having spent a year training on their stack at the previous company's expenses.
In my experience rewrites typically start with senior devs (or tech leads who are not really leads but rather senior devs with better pay). The rewrite starts when devs are able to force/guilt/persuade the manager to do it.
And also in my experience rewrites rarely succeed. There are multitude of reasons but the best way to put it is that devs don't usually know what they are getting into (they only have part of the picture) and they are out of stamina somewhere in the middle of the project. They also never learned what caused the previous project to fail (they have too limited view to understand it) and so they tend to repeat the same mistakes.
One project I joined had lost its entire development team. New devs came and demanded rewrite. The manager allowed it. The rewrite failed (of course). The cause: the internal customer was very intrusive and they demanded to get creative control over every part of the development process including approving code reviews, etc. The lack of expected progress on the features the customer demanded only got the situation worse and got them more arguments and in the end higher management decided to kill the rewrite.
Again -- devs had only partial understanding of what caused the fail of the previous project. They looked at badly written code and surmised the previous developers to be incompetent. The reality was those guys were competent but were completely demotivated by inability to get anything done with the internal customer and so did not care about quality one iota.
My solution to rewrites is avoid at any cost and to only do rewrites under exceptional circumstances when it is absolutely clear that refactoring is pointless.
So what do I do?
1. When setting on the project to improve your system/codebase, it is important to think about your ability to finish the project. This is going to be dependant on willingness of your various stakeholders to pour money (or see a slowdown in feature development). The best way is to get a credit of trust early on and the best way to get this is by showing some early results that the stakeholders care about especially if it is something they wanted for a long time but could not get.
2. No results will be worth anything if you don't get some visibility. Put up metrics for everything that can be reasonably measured and the customer cares about -- reliability, performance, turnaround time for defects/changes, etc.
3. Those early results can be anything but when I come into a project I am trying to find out what are the biggest issues and I try to locate one where it is possible to get substantial improvement quickly. This might be something like fixing unreliable behaviour, performance or getting done a particular feature that was asked for for a long time. It is important to select carefully -- you are working on an alien codebase with a new team. The worst that can happen is you promise a lot and deliver nothing.
4. Once you get a credit of trust, you spend it on improving development efficiency. Overall, this is one thing that is most important to get done early but at least early on is completely invisible to stakeholders -- and so you need to use up a bit of your credit.
5. Development efficiency is highly dependant on the project. Automated build? Faster build times? Automated end to end functional testing? Being able to set up your private development environment quickly? Getting rid of some stupid hoops you have to get to modify the app or get your piece of code through the process? Refactoring a couple things that are causing a lot of additional work for every change? The key is to look at the actual process and understand what really is driving inefficiency -- as tech lead I always pair program with developers to get understanding of what the situation really is like.
5.1 On one project I noticed developers spent a lot of time on internal requests form customer that were nothing else than changes in configuration. I wrote couple modules and small UI to let the user self-service themselves and suddenly eliminated about 1/5th of development effort (with about a week of effort on my part). I also spent some time with the team to talk about importance of self service and how it helps reduce unplanned work that interrupts their development.
5.2 Pair programming is ABSOLUTELY best way to get to know your team and the team to get to know you. You want some respect as tech lead? No better way than to actually stick with them and show you can do stuff. This is going to be very important for you later.
6. At this time you should be thinking about improving the basic improvement process -- at the very least get your team to understand what is wrong and right and have retrospectives with the team to figure out what the problems are and how to fix them. You don't want to bog your team with full agile, but you want to start building it from the ground up by introducing basic improvement loop, transparency, openness, etc.
7. By improving development efficiency you create additional development throughput which you then spend on more improvements, but now those improvements should start providing visible results to stakeholders. Faster turnaround time on changes, more reliable and predictable deployments, more reliable and faster system, etc. Here you want to be tracking how much resources you spend on internal improvements (code refactorings, development tooling, etc.) vs things that the customer cares. It is important that the customer is always satisified because this is what gives you freedom to do whatever changes you want to make.
And if anybody wants it, I am always happy to help with a problematic project:)
Ah rewrites. Sometimes you have to do them. Not because you will get new features. But just so you can hire someone at a reasonable price in the near future and it will actually run on a somewhat newish computer on a tech stack that was EOL 2 decades ago. Then you also get someone who rocks in and says 'you are just using the wrong language at my previous job we used xyz and it is the best we should just switch everything over to that'. Somewhere in the middle of those two points is where you decide to rewrite it.
The most common scenario is that the fresh young smart ** hoodwinks the boss into giving them 1-2 years and 2 subordinates to help them do the rewrite in isolation. They come off all support rotas and have no responsibility for BAU operation of the old codebase. The old codebase is left with usually a same or larger team maintaining and still adding new features.
The other way I've seen this done is that senior management really wants the rewrite, shops around for a candidate internal or internal who promises to do it.. and then basically same setup as above.
Setting up an explicit "good" and "bad" team creates awful vibes, the "good" team never delivers and starts exiting as accountability starts to creep in.
Meanwhile the "bad" team hemorrhages staff continuously from the burn out of maintaining the old thing with less people while also being told your job has an expiration date.
reply