4 ms·

> You can do successful rewrites but your rewrite has to be usable in production within like a month. I strongly disagree with this, and it reminds me of one o

> You can do successful rewrites but your rewrite has to be usable in production within like a month. I strongly disagree with this, and it reminds me of one of the worse Agile memes: "With every commit, the product must be production-ready.". [0] The rewrite has to be generally not behind schedule. Whatever that schedule is is up to the folks doing the work and the managers who approve doing the work. [0] I've worked for an Agile shop for a long time, so please don't tell me that I'm "Doing Agile Wrong" or that I misunderstand Agile. "No True Scotsman" conversations about Agile are pretty boring and pointless, given Agile's nebulous definition.

harrall 2y ago
OK so you're actually right, but the actual criteria of "whether you can do this" depends on a lot of factors from the project to the people. But there's no way to really describe it. It's like explaining to somehow how to parallel park or do a kickflip... you can only explain it so much. I like to say "it should be usable in production soon" because it's generally a good approximation that takes into account what you might have to work with. It's an upgrade from advice like Joel's who just say "IT NEVER WORKS"
- simoncion 2y ago
  > It's an upgrade from advice like Joel's who just say "IT NEVER WORKS" What you originally said ("It must be usable in production within a month") is equivalent to "Just don't do it, because IT NEVER WORKS" for all but the smallest, simplest projects out there in Professional Programmer land. [0] > But there's no way to really describe it. There really is a way to describe it: "The rewrite has to be generally not behind schedule. Whatever that schedule is is up to the folks doing the work and the managers who approve doing the work." Establishing that schedule is the same sort of cost/benefit and expected-level-of-difficulty analysis that should be done before planning any nontrivial work in Professional Programmer land. All but the most green or most sheltered-from-Process programmers are at least aware of this analysis. Many of those who are aware of it have participated in it. [0] Or the most well-designed projects, which have small, easily understood pieces with easily-comprehensible interactions with the rest of the system, that can be quickly and easily replaced with new pieces. There's not much out there like that... and I'd imagine the task of "making major changes to how many of those pieces interact with each other" wouldn't be usable in production in a month for most of those systems.
cratermoon 2y ago
If the schedule is three years, and in the meantime the product being rewritten isn't getting maintenance, the company might as well go ahead and fold and save everyone pain and disappointment. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- simoncion 2y ago
  If the product is not getting needed maintenance, then yeah, maybe. But, man, sometimes software is fit-for-purpose and can really be just be left alone for extended periods. Other times, the users of that software upgrade on a hemi-annual or annual schedule (or even LESS frequently), so they'd never notice a three month delay in new releases.
  - cratermoon 2y ago
    > sometimes software is fit-for-purpose and can really be just be left alone for extended periods I suppose if the software maker is a functional monopoly in that space and the customers are cursed withe vendor lock-in, sure. I can think of Major Software companies that barely maintain their products yet companies stick with the garbage because what choice do they have?
    - simoncion 2y ago
      > I suppose if the software maker is a functional monopoly in that space and the customers are cursed withe vendor lock-in, sure. Given this statement, it might surprise you to learn that there are folks who aren't keen on software development for its own sake, and really rather dislike having to re-learn how to use their tools when those tools get significantly changed with no clear benefit to those users. See also: the folks who are perfectly happily using "ancient" versions of -say- Photoshop, or WordPerfect, or Word or...

harrall 2y ago

OK so you're actually right, but the actual criteria of "whether you can do this" depends on a lot of factors from the project to the people. But there's no way to really describe it. It's like explaining to somehow how to parallel park or do a kickflip... you can only explain it so much. I like to say "it should be usable in production soon" because it's generally a good approximation that takes into account what you might have to work with. It's an upgrade from advice like Joel's who just say "IT NEVER WORKS"

simoncion 2y ago
> It's an upgrade from advice like Joel's who just say "IT NEVER WORKS" What you originally said ("It must be usable in production within a month") is equivalent to "Just don't do it, because IT NEVER WORKS" for all but the smallest, simplest projects out there in Professional Programmer land. [0] > But there's no way to really describe it. There really is a way to describe it: "The rewrite has to be generally not behind schedule. Whatever that schedule is is up to the folks doing the work and the managers who approve doing the work." Establishing that schedule is the same sort of cost/benefit and expected-level-of-difficulty analysis that should be done before planning any nontrivial work in Professional Programmer land. All but the most green or most sheltered-from-Process programmers are at least aware of this analysis. Many of those who are aware of it have participated in it. [0] Or the most well-designed projects, which have small, easily understood pieces with easily-comprehensible interactions with the rest of the system, that can be quickly and easily replaced with new pieces. There's not much out there like that... and I'd imagine the task of "making major changes to how many of those pieces interact with each other" wouldn't be usable in production in a month for most of those systems.

cratermoon 2y ago

If the schedule is three years, and in the meantime the product being rewritten isn't getting maintenance, the company might as well go ahead and fold and save everyone pain and disappointment. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

simoncion 2y ago
If the product is not getting needed maintenance, then yeah, maybe. But, man, sometimes software is fit-for-purpose and can really be just be left alone for extended periods. Other times, the users of that software upgrade on a hemi-annual or annual schedule (or even LESS frequently), so they'd never notice a three month delay in new releases.
- cratermoon 2y ago
  > sometimes software is fit-for-purpose and can really be just be left alone for extended periods I suppose if the software maker is a functional monopoly in that space and the customers are cursed withe vendor lock-in, sure. I can think of Major Software companies that barely maintain their products yet companies stick with the garbage because what choice do they have?
  - simoncion 2y ago
    > I suppose if the software maker is a functional monopoly in that space and the customers are cursed withe vendor lock-in, sure. Given this statement, it might surprise you to learn that there are folks who aren't keen on software development for its own sake, and really rather dislike having to re-learn how to use their tools when those tools get significantly changed with no clear benefit to those users. See also: the folks who are perfectly happily using "ancient" versions of -say- Photoshop, or WordPerfect, or Word or...