7 ms·

In my open office next door, people have been refactoring a cpp98 monolith into more interdependent components to be able to have a better test suite, better CI

by seren 7y ago

In my open office next door, people have been refactoring a cpp98 monolith into more interdependent components to be able to have a better test suite, better CI integration, better deployment story. That sounds about right. 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.

rusticpenn 7y ago
The legacy code should have been running in parrallel with the new code , atleast until it reaches feature parity ( or reduced features - with other features removed as they have not been used)
- seren 7y ago
  Definitely it is a text book example of things to not do, but what is painful is that they started with good intentions. (People with good intentions are the most dangerous one though)
Bombthecat 7y ago
I learned from Microsoft that rewrites are hard! (they tried it with word) and I think somewhere is the story how it went.. They rolled back later on and kept modernizing piece by piece now. That, I think is the right way.
- mcny 7y ago
  To play the devil's advocate: it might not be a one size fits all solution. 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...
- deleted 7y ago
  [deleted]
- severine 7y ago
  > ...and I think somewhere is the story how it went... Maybe this? https://blogs.msdn.microsoft.com/rick_schaut/2004/02/26/mac-word-6-0/ https://blogs.msdn.microsoft.com/rick_schaut/2004/02/26/mac-... Couldn't find any other reference, nice reading!
adrianN 7y ago
Deleting legacy code you don't understand is the best way to remove fixes for bugs you didn't know you had.
goto11 7y ago
Deleting all code you don't understand is also stretching the term "refactoring" a bit beyond its usual meaning :-)
matwood 7y ago
> they removed all the legacy code they haven't understood. 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.
- atoav 7y ago
  Which is why it is sometimes crucial to add comments to your code. I know certain code basically documents itself, but that depends on the person who reads it. In my eyes it is precisely edge cases that might or might not be known that profit from decent explainatory comments. 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.
  - matwood 7y ago
    I agree. I also use git blame and track down when and why code was added. But this is tedious work that I find many people don't like to do for some reason. Me, I like the investigative work of tracking something down.
  - Endy 7y ago
    I also personally believe in, and this isn't just for code, but for any project you'll pass to another, a connected read.me file explaining the high-level reasonings and other thoughts, including a personal changelog and roadmap, and some instructions for use and editing.
  - dirkf 7y ago
    And please write proper commit messages! 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.
deleted 7y ago
[deleted]

by seren 7y ago

rusticpenn 7y ago

The legacy code should have been running in parrallel with the new code , atleast until it reaches feature parity ( or reduced features - with other features removed as they have not been used)

seren 7y ago
Definitely it is a text book example of things to not do, but what is painful is that they started with good intentions. (People with good intentions are the most dangerous one though)

Bombthecat 7y ago

I learned from Microsoft that rewrites are hard! (they tried it with word) and I think somewhere is the story how it went.. They rolled back later on and kept modernizing piece by piece now. That, I think is the right way.

mcny 7y ago
To play the devil's advocate: it might not be a one size fits all solution. 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...
deleted 7y ago
[deleted]
severine 7y ago
> ...and I think somewhere is the story how it went... Maybe this? https://blogs.msdn.microsoft.com/rick_schaut/2004/02/26/mac-word-6-0/ https://blogs.msdn.microsoft.com/rick_schaut/2004/02/26/mac-... Couldn't find any other reference, nice reading!

adrianN 7y ago

Deleting legacy code you don't understand is the best way to remove fixes for bugs you didn't know you had.

goto11 7y ago

Deleting all code you don't understand is also stretching the term "refactoring" a bit beyond its usual meaning :-)

matwood 7y ago

> they removed all the legacy code they haven't understood. 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.

atoav 7y ago
Which is why it is sometimes crucial to add comments to your code. I know certain code basically documents itself, but that depends on the person who reads it. In my eyes it is precisely edge cases that might or might not be known that profit from decent explainatory comments. 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.
- matwood 7y ago
  I agree. I also use git blame and track down when and why code was added. But this is tedious work that I find many people don't like to do for some reason. Me, I like the investigative work of tracking something down.
- Endy 7y ago
  I also personally believe in, and this isn't just for code, but for any project you'll pass to another, a connected read.me file explaining the high-level reasonings and other thoughts, including a personal changelog and roadmap, and some instructions for use and editing.
- dirkf 7y ago
  And please write proper commit messages! 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.

deleted 7y ago

[deleted]