3 ms·

The problem with this “maintainability” argument is the presumption a) that it will be maintained (note I recommended rewriting frequently) or that b) it’s in c

by Zetice 3y ago

The problem with this “maintainability” argument is the presumption a) that it will be maintained (note I recommended rewriting frequently) or that b) it’s in conflict with meeting business objectives.

alpha_squared 3y ago
Rewriting frequently (reference a) is often out of the hands of the developer because of (reference b) business objectives. Writing code is entirely in the hands of the developer only at the time of writing, not a "henceforth and forever" sort of situation.
- johnnyanmac 3y ago
  And I suppose a dev who only cares about paying the bills would still resonate with this advice. It's not their problem once the suits take charge of the product and give a thumbs up. Why bother with future dev maintenance? the suits will pay for that bride when it burns down, and having that happen is 100x more easy than trying to explain good code upkeep that delays business for a few weeks.
eternityforest 3y ago
Rewriting throws away years of accumulated edge cases handling. Suddenly the thing doesn't work because one particular model of printer needs an undocumented command to enable some feature, or users are inputting bad data because you forgot the checks you accumulated... Seems not ideal for end users, unless you're working with microservices or something with well defined specifications that people are actually paying attention to.
- Zetice 3y ago
  Depends on the field, but what I work on generally evolves so much over time that by the time I'm ready for a rewrite, the "edge cases" I had to account for when I started are either solved, partially solved, or can be isolated into some tiny part of the codebase that could be ported over from the previous code. Beside, "rewrite" here doesn't mean "new repo, new project, new everything" it means reimplementation, usually based on the lessons learned from the previous implementation, and that does include edge case handling, as well as expanded functionality to "underwrite" or justify the effort spent on the rewrite.
- vendiddy 3y ago
  Rewriting does not need to be an all-or-nothing endeavor. If you design your app as a collection of subsystems, it's sometimes faster to destroy and rebuild one of them than it is to refactor.

by Zetice 3y ago

alpha_squared 3y ago

Rewriting frequently (reference a) is often out of the hands of the developer because of (reference b) business objectives. Writing code is entirely in the hands of the developer only at the time of writing, not a "henceforth and forever" sort of situation.

johnnyanmac 3y ago
And I suppose a dev who only cares about paying the bills would still resonate with this advice. It's not their problem once the suits take charge of the product and give a thumbs up. Why bother with future dev maintenance? the suits will pay for that bride when it burns down, and having that happen is 100x more easy than trying to explain good code upkeep that delays business for a few weeks.

eternityforest 3y ago

Rewriting throws away years of accumulated edge cases handling. Suddenly the thing doesn't work because one particular model of printer needs an undocumented command to enable some feature, or users are inputting bad data because you forgot the checks you accumulated... Seems not ideal for end users, unless you're working with microservices or something with well defined specifications that people are actually paying attention to.

Zetice 3y ago
Depends on the field, but what I work on generally evolves so much over time that by the time I'm ready for a rewrite, the "edge cases" I had to account for when I started are either solved, partially solved, or can be isolated into some tiny part of the codebase that could be ported over from the previous code. Beside, "rewrite" here doesn't mean "new repo, new project, new everything" it means reimplementation, usually based on the lessons learned from the previous implementation, and that does include edge case handling, as well as expanded functionality to "underwrite" or justify the effort spent on the rewrite.
vendiddy 3y ago
Rewriting does not need to be an all-or-nothing endeavor. If you design your app as a collection of subsystems, it's sometimes faster to destroy and rebuild one of them than it is to refactor.