I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)
To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (inability to change is also another red flag).
There is a small chance that there's strong logical reasons for a desire to fundamentally change an underlying technology, but the comment above says they "simply refused to become competent in ....... that the system is built on" and as a ex-google senior engineer of 20 years, I can 100% confidently say that the first step to large scale refactor is to understand and be competent in the existing system!
My best software development experiences have been in cultures where this way of working was common.
It is a shame that these cultures are not more widely spread; and I mostly blame GitHub: the lack of good support for stacked PRs or patch series or whatever you want to call it makes it harder than it should be to work in this way.
> why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before.
Application have many other properties then "doing their job". Running cost, maintainability, ... it's endless. Any of them going seriously wrong can tank the company owning it.
But I agree, rewrites are very often bad. I've been the customer of two banks that spent years to rewrite their online bank. It was crap and missing features! But maybe they got something out of it.
Never just write code. Always write red tests first.
In fact you can do even better and have your agent write end-to-end tests first as acceptance tests, have it witness them fail, then have it do red/green at the unit/component/integration level. Once it’s done the e2e tests pass, have it send the code off for linting and self-review.
If you are vigilant you’ll end up with a trustworthy validation suite. And with that (especially with e2e coverage), you can refactor and rewrite as much as you like.
Title is somewhat clickbaity, because these actions are not what people are going to think of when they think of a rewrite in a corporate environment.
By the way, I was an early employee at Amazon.com and the website’s rendering engine was rewritten three times, each time unlocking a new level of productivity without which the site (as well as the velocity of teams) would have slowed to a crawl, and the company would have probably died.
Churning out the blog posts isn't a bad idea if it's true. Repetition isn't inherently bad.
you’ll only find out which kind of rewrite you’re doing once you start it.
But they need expertize in software development and knowledge of the software's context to evaluate.
Part of Yahoo's business is/was hiring programmers reasonably cheaply and controlling them reasonably easily - to allow Yahoo itself to sell parts or all of itself.
So things aren't quite a simple as "this doesn't serve the product", sometimes the engineers (and their replaceability) are part of the product.
This essay sounds more like a second phase. Rewriting something that you do not understand makes sense if most people on team do not understand it well, and are supposed to actively contribute to it OR you are at an inflection point where the choice of architectural or foundational decisions made back then become a bottleneck in every day performance or feature development.
Business is looking it from the cost benefit perspective and they would not approve it at the cost of company time and money if it doesnt makes sense to them. Your ability to fool them for your motivations may be a different angle, still they are the ones making the call.
That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant for a full-stack rewrite, particularly of a mature codebase with a lot of accumulated business logic. At least on the front end you can always push to move business logic upstream where it belongs.
A lot of rewrites could be avoided if people spent some time to actually understand what was done before. It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
Amen! Code is never written in a vacuum. Code is never shaped only by engineering but by business and organizational compromises as well. I hate those guys who declare we absolutely must do sweeping changes to the codebase/architecture so that we are in line with the latest best practices after spending an hour with the codebase. As if the guys who spent the last 3+ years staring and building on said codebase didn't know any better (unless of course you were hired specifically because you ought to know better!).
The motivations and goals back then could have been different, specially in the case of MVPs
I mean, if you do it at 4am, you are sleep deprived by the day two and thus unable to stop yourself from something stupid.
Rewrites usually start with a gap in what is available and what is needed: missing functionality, existing frameworks getting obsolete, difficultly maintaining code because of the existing implementation complexity, costs, scalability issues, compliance challenges, etc. Most of these things serve the business more than the engineers.
I agree with you. And that is where I was at that time. I did not have enough experience as a Software Engineer, nor with CakePHP — hence decided to rewrite. Mistakes were made.