4 ms·

Also an issue is that the director attempted a full rewrite as a separate project. You can do successful rewrites but your rewrite has to be usable in producti

Also an issue is that the director attempted a full rewrite as a separate project. You can do successful rewrites but your rewrite has to be usable in production within like a month. If you don’t know how to achieve that, don’t even try. The quiet developer was able to get their own rewrite done because they understood that. Looks like the director of engineering showed some classic inexperience. You can tell when someone has done something before and when it’s their first time.

LAC-Tech 2y ago
literally what I wanted to do as an opinionated junior
cratermoon 2y ago
> a full rewrite as a separate project. And it was never constrained to rewriting the existing system. The rewrite plan was motivated by the entirely reasonable desire to make further improvements possible, an additional mistake was the attempt to add major improvements as part of the rewrite. The new guys made their disdain for the existing system obvious, to the extent that their intent for the rewrite ballooned into a ground-up rebuild of everything. Things You Should Never Do, Part I: 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
> 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-...

LAC-Tech 2y ago

literally what I wanted to do as an opinionated junior

cratermoon 2y ago

> a full rewrite as a separate project. And it was never constrained to rewriting the existing system. The rewrite plan was motivated by the entirely reasonable desire to make further improvements possible, an additional mistake was the attempt to add major improvements as part of the rewrite. The new guys made their disdain for the existing system obvious, to the extent that their intent for the rewrite ballooned into a ground-up rebuild of everything. Things You Should Never Do, Part I: 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

> 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-...