I've seen plenty of projects blown up with massive, fearless refactors to do thing "the right way".
Careful with that axe, Eugene.
Careful with that axe, Eugene.
Well, the issue is that they have done it a bit sneakily, they removed all the legacy code they haven't understood. So the code is much more elegant, it has been moved to cpp11 or 14, it ticks every good practice. There is only one slight issue : it does not work. It somewhat work, but is not reliable and fails regularly in unexpected ways. And they've started 5 years ago, and haven't been delivering any business value since then.
At the beginning, it was okay because they had some leeway but now they are blocking the release of new products, and our market share is in free fall.
Heads have started to roll.
To be fair, a few years down the line, their team will likely be more productive and efficient, but I am still not sure that the cost of the rewrite was justified. Still the article is very on point on the risk of not paying your technical debt.
This is exactly why rewrites or huge refactors typically fail. The new programmer sees code and doesn't understand why the code is there and thinks the last programmer was an idiot and deletes said code. Unknown to the new programmer is that code handles some weird edge case.
A rewrite should spend 80% of the time understanding the old code and 20% writing the new. But, that's no fun for most programmers who just want to code in the latest shiny so the new code ends up broken.
"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood. The quotation is from G. K. Chesterton's 1929 book The Thing, in the chapter entitled "The Drift from Domesticity":
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
The lights stayed on the whole time. We retained the ability to switch back to the old system by setting a feature flag until everyone (including the business users) was confident that the new system was working as well as - preferably better than - the old one.
Throwing out code we didn't understand was simply unthinkable, because we weren't allowed to have that 6 months of time fantasizing that everything would be great before launch day - whatever you were working on now would be expected to go into production within a week or two, without upsetting the rest of the business in the process.
No, it wasn't very fun. But it was satisfying work. I think it was my boss's boss who observed that making all the team members happy won't make a project successful, but everyone's ultimately happy to see a project successfully executed.
As a avid writer of comments I am convinced they also help myself, to form thoughts and remember them later, so at times I will write the comments before writing an actual function.
If that is to bold, commenting while the thing is still in your head makes sense anyways — saves you time later and helps everybody else who will look at your code.
A short summary, preferably including a hint at which subsystem is impacted by the change. Then explain in detail the context of the change: root cause of a bug and the gist of the solution, use case(s) behind a new feature and how it can be used, ...
Yes, often there's a bug/project tracking tool being used and the commit message contains a reference to the relevant entry there. But from experience I know these tools tend to change: old one gets decommissioned, data gets migrated, what was once the primary identifier is now a mere field or comment in the new system, access rights get messed up, ... Trying to understand the history then turns into an archeological expedition through various eras long gone... unless the commit messages are sufficiently self-containing.
This would have saved quite a bit of headache at my last job actually.
In general, I've found value in figuring out how to improve existing systems where feasible rather than trying to migrate to a new system, since the existing system probably has advantages the new one won't. At minimum, people are already familiar with the existing system.
That, I think is the right way.
When you're at Microsoft and can just walk up to the bar researchers and programmers in the world, maybe. When you're at some corporation where you have to spend half a day on the phone to get your computer unlocked by the desktop support and request to change a config on a web server becomes a ten foot long email chain about whose fault it is that we need this change, I don't think people have any motivation to modernize piece by piece.
Then there is the issue that you'll have to explain why part of the application is in .NET core and part is in dot net framework 3.5...
Maybe this? https://blogs.msdn.microsoft.com/rick_schaut/2004/02/26/mac-...
Couldn't find any other reference, nice reading!
And I say that as someone who has committed a few, in both senses of the word.
The point is to be deterministic, and it can only be deterministic if it is small.
Except none of the contractors agree on what materials to use. So one section is steel, another is wood, and another yet is brick. Meanwhile there is a 3rd party outside attempting to load the whole place onto a truck and ship it somewhere else.
And then someone else comes along and asks "This does fly doesn't it?"
'a series of small behavior-preserving transformations, each of which "too small to be worth doing"' https://martinfowler.com/books/refactoring.html