3 ms·

I rewrote two applications, once on my own, once with some help from the team. The first time we switched the backend to a completely new framework (I'm in the

by darau1 7y ago

I rewrote two applications, once on my own, once with some help from the team. The first time we switched the backend to a completely new framework (I'm in the middle of one of those right now...) and the second time we upgraded from an outdated version of the framework to the latest one in one go (so, essentially a rewrite from the ground up). Both times sucked, both times we underestimated the amount of work to be done, and both times we were much happier with the new product than what we had before.

hinkley 7y ago
If the team refuses to work on the old code, you have to do something. A rewrite may be the least bad thing you can do in that case, but if you don't ask how we got here and why we won't end up right back here again... The Relentless Improvement model that many refactoring advocates espouse is one (great) answer to that question. But it also means they won't wait for a rewrite. They'll fix the bullshit they're staring at today, and stare at some other bullshit tomorrow.
- mntmoss 7y ago
  Lately I've been testing a "third way" of thinking about refactor/rewrite decisions, which is to first document the existing requirements. The trick is in making those docs so small and lean that they fit neatly in comments inlined with key functions, and this I have accomplished by reduction to a list of "must" and "cannot" (abbreviated to + and -) bullet point items. It must function like this, it cannot function like that. Some requirements can be turned into automated tests or static checks, others need an eye to verify. But the cycle I'm seeing often works out to be: write speculative requirements, write speculative code, then reverse-engineer true requirements and maintain code against that. Doing this creates a base quality bar that the code has to hit in both the rewrite and refactor cases. The trap that rewrites tend to fall into is that the requirements are lost during the rewrite, so the new code becomes just as speculative as the original greenfield code. If you have the requirements as your reference, on the other hand, the area of bad code you can write is limited to the boundaries of those requirements and any missing requirements. This makes new code much less of a gamble.
  - hinkley 7y ago
    That's a very good point. It's so hard to get people to write good requirements that we often overlook (or rather, won't look at it) as a solution. Rewrites are easier with good requirements. They're a constant stream of bad surprises without them. It's possible, while refactoring, to begin to collect those requirements, in the tests if nowhere else. But it's not a given.

by darau1 7y ago

hinkley 7y ago

If the team refuses to work on the old code, you have to do something. A rewrite may be the least bad thing you can do in that case, but if you don't ask how we got here and why we won't end up right back here again... The Relentless Improvement model that many refactoring advocates espouse is one (great) answer to that question. But it also means they won't wait for a rewrite. They'll fix the bullshit they're staring at today, and stare at some other bullshit tomorrow.

mntmoss 7y ago
Lately I've been testing a "third way" of thinking about refactor/rewrite decisions, which is to first document the existing requirements. The trick is in making those docs so small and lean that they fit neatly in comments inlined with key functions, and this I have accomplished by reduction to a list of "must" and "cannot" (abbreviated to + and -) bullet point items. It must function like this, it cannot function like that. Some requirements can be turned into automated tests or static checks, others need an eye to verify. But the cycle I'm seeing often works out to be: write speculative requirements, write speculative code, then reverse-engineer true requirements and maintain code against that. Doing this creates a base quality bar that the code has to hit in both the rewrite and refactor cases. The trap that rewrites tend to fall into is that the requirements are lost during the rewrite, so the new code becomes just as speculative as the original greenfield code. If you have the requirements as your reference, on the other hand, the area of bad code you can write is limited to the boundaries of those requirements and any missing requirements. This makes new code much less of a gamble.
- hinkley 7y ago
  That's a very good point. It's so hard to get people to write good requirements that we often overlook (or rather, won't look at it) as a solution. Rewrites are easier with good requirements. They're a constant stream of bad surprises without them. It's possible, while refactoring, to begin to collect those requirements, in the tests if nowhere else. But it's not a given.