3 ms·

It appears that for your case, a pretty new and small project, doing a complete code rewrite was the right choice. However, for BIG codebases (especially those

It appears that for your case, a pretty new and small project, doing a complete code rewrite was the right choice. However, for BIG codebases (especially those that you didn't write yourself !!!! ), I'd say Joel is spot on. The company I work for is currently busy throwing five million dollars down the drain on a greenfield re-development of a bad but servicieable insurance package, when they could have either overhauled it or bought a commercial product - which they deemed "too expensive, but I'll eat my backpack if the final rewrite isn't both late and over the budget of the commercial product. It's not a Netscape-style failure, but it will probably cost it a lot of market share.

MartinCron 13y ago
It's not just(!) the five million dollars that they are throwing down the drain, think of the opportunity cost spent in what you didn't develop during all that time you were basically running to stand still.
- GFischer 13y ago
  Yeah, I'll be abandoning the Titanic ASAP :) . It's an insurance company, it shouldn't think of itself as a software shop. It does sometimes make sense to build stuff in-house, but not an insurance package (reinventing a pretty expensive wheel).
  - MartinCron 13y ago
    Well, if they look at their ability to make an effective insurance package as a competitive advantage instead of a necessary evil, I don't see anything absolutely wrong with an insurance company making insurance software, but I'll defer to your domain expertise :) Good luck.
    - GFischer 13y ago
      It's a small subsidiary of a big insurance company, with 120 employees in the local branch (20 of which are now in software) and 45 million dollars in premiums (that's sales, not profits). They hired a new CTO, who hired a new team specifically to write the new software, and are NOT using any of the old developers' knowledge (me and 2 others are stuck maintaining the old software). The new team blew the deadline for the first small module (a small subpart of claims management) by 6 months (the old team had estimated 2 weeks for delivery of that module if we had done it ourselves). They vastly underestimate the effort and have no idea of what they got themselves into (and they're paid employees, it's not like they can be sued for not delivering). It doesn't make sense for a company that small to divert that much effort into a non-core competency. Now, if the parent company (10.000 million in premiums) decided to build their own insurance software, I believe they could do it right :) .
Osiris 13y ago
Even for smaller projects it may not be the right choice. I had a side project I work one that would take a complete re-write to make it testable as well as being able to work better in Windows 8. But I find that when I think about it, it's a huge amount of work and while new features and bugs can be annoying to fix (lack of tests also means inevitable regressions), but still far less time consuming than a re-write. Plus, if I completely rewrite it so it's awesome and more flexible, I expect that my revenue will probably be about the same as it is now. Rewriting it won't increase my sales unless I'm able to add features that would be impossible in the current code.

MartinCron 13y ago

It's not just(!) the five million dollars that they are throwing down the drain, think of the opportunity cost spent in what you didn't develop during all that time you were basically running to stand still.

GFischer 13y ago
Yeah, I'll be abandoning the Titanic ASAP :) . It's an insurance company, it shouldn't think of itself as a software shop. It does sometimes make sense to build stuff in-house, but not an insurance package (reinventing a pretty expensive wheel).
- MartinCron 13y ago
  Well, if they look at their ability to make an effective insurance package as a competitive advantage instead of a necessary evil, I don't see anything absolutely wrong with an insurance company making insurance software, but I'll defer to your domain expertise :) Good luck.
  - GFischer 13y ago
    It's a small subsidiary of a big insurance company, with 120 employees in the local branch (20 of which are now in software) and 45 million dollars in premiums (that's sales, not profits). They hired a new CTO, who hired a new team specifically to write the new software, and are NOT using any of the old developers' knowledge (me and 2 others are stuck maintaining the old software). The new team blew the deadline for the first small module (a small subpart of claims management) by 6 months (the old team had estimated 2 weeks for delivery of that module if we had done it ourselves). They vastly underestimate the effort and have no idea of what they got themselves into (and they're paid employees, it's not like they can be sued for not delivering). It doesn't make sense for a company that small to divert that much effort into a non-core competency. Now, if the parent company (10.000 million in premiums) decided to build their own insurance software, I believe they could do it right :) .

Osiris 13y ago

Even for smaller projects it may not be the right choice. I had a side project I work one that would take a complete re-write to make it testable as well as being able to work better in Windows 8. But I find that when I think about it, it's a huge amount of work and while new features and bugs can be annoying to fix (lack of tests also means inevitable regressions), but still far less time consuming than a re-write. Plus, if I completely rewrite it so it's awesome and more flexible, I expect that my revenue will probably be about the same as it is now. Rewriting it won't increase my sales unless I'm able to add features that would be impossible in the current code.