计算未来 N 个月内预计难以实施的变更的资源成本（根据您的经验） - 仅计算边际成本（即，如果 VB5 应用程序的变更成本为 1 周，并且成本为在丰富的 Web 2.0 ASP.NET MVC 应用程序中实现相同的功能需要 3 天，您将其算作 2 天的节省）。添加 Web 2.0 应用程序将为 VB5 应用程序根本无法提供的用户提供的新功能的预计收益。
如果前者小于后者，则重新编写。
This will sound cliche, BUT, go for standard cost/benefit analysis:
Take the cost of resources for the re-write (REALISTIC cost - meaning multiply your estimate by 3-5 times). This includes possibly needing to train other developers on your new chosen architecture/tools, AND the cost of re-training the users.
Take the resource cost from hard-to-implement changes anticipated in the next N months (based on your experience) - only counting the marginal cost (meaning, if the cost of a change in VB5 app is 1 week and the cost of that same feature to implement in rich Web 2.0 ASP.NET MVC application is 3 days, you count it as 2 days of savings). Add in projected benefit from new features the web 2.0 app will provide the users that VB5 app can not provide at all.
If the former is less than the latter, go for a re-write.
I don't have a rule handy to decide that, but I suggest reading Things You Should Never Do, Part I, where Joel Spolsky writes about single worst strategic mistake a company can make.
That said, we completely rewrote an application for a customer, and it was the right thing to do, since it's now more reliable, faster, has more features and is more beautiful than the old one ever was. Extending the old application (which has gained a lot of features over the years that were just somehow hacked in) would have been more expensive in the long term, since it's a living application, getting additional features once or twice a year.
Generally I'd say that if the resources (time, money, developers etc) required to add the feature are more than it would take to re-write, then re-write.
You need to add some bias, for instance re-writing the application might also result in reduced support costs in the future as many of the bugs will be removed as part of the implementation, but there will also be issues when writing a new application (training, small bugs that make their way into the finished product, random debugging messageboxes or rubbish like that).
I try to avoid a re-write at all costs - sometimes they're necessary, but they're always significantly more trouble than initially expected, and they tend to re-introduce bugs that have long since been squashed in the legacy version.
If the business requires that you add features that the current platform doesn't support, it may seem like don't have any other option except to re-write, but consider your other choices - can you add the functionality another way? A report or small webpart on your intranet? Automatic emails? Some kind of web service that goes against the database? There are a number of ways that you can add functionality without completely scrapping what's there and accepting all the risks that are involved.
From the business perspective, it's cost vs. benefit. If you're adding a single feature, it's dev time vs. benefit of the feature. However, if they want a single new feature that requires a rewrite, suddenly the 8 hour feature becomes an 800 hour feature (be realistic when you estimate the development time for the rewrite - "I'll do it in the next week" isn't often realistic), and the business may no longer be able to justify the development time. Make sure the cost is justified by the benefit.
发布评论
评论（4）
这听起来很陈词滥调，但是，请进行标准成本/效益分析：
计算重写所需的资源成本（实际成本 - 意味着将您的估计乘以 3-5 倍）。这包括可能需要就您新选择的架构/工具对其他开发人员进行培训，以及重新培训用户的成本。
计算未来 N 个月内预计难以实施的变更的资源成本（根据您的经验） - 仅计算边际成本（即，如果 VB5 应用程序的变更成本为 1 周，并且成本为在丰富的 Web 2.0 ASP.NET MVC 应用程序中实现相同的功能需要 3 天，您将其算作 2 天的节省）。添加 Web 2.0 应用程序将为 VB5 应用程序根本无法提供的用户提供的新功能的预计收益。
如果前者小于后者，则重新编写。
This will sound cliche, BUT, go for standard cost/benefit analysis:
Take the cost of resources for the re-write (REALISTIC cost - meaning multiply your estimate by 3-5 times). This includes possibly needing to train other developers on your new chosen architecture/tools, AND the cost of re-training the users.
Take the resource cost from hard-to-implement changes anticipated in the next N months (based on your experience) - only counting the marginal cost (meaning, if the cost of a change in VB5 app is 1 week and the cost of that same feature to implement in rich Web 2.0 ASP.NET MVC application is 3 days, you count it as 2 days of savings). Add in projected benefit from new features the web 2.0 app will provide the users that VB5 app can not provide at all.
If the former is less than the latter, go for a re-write.
我没有方便的规则来决定这一点，但我建议阅读 你不应该做的事情，第一部分，乔尔·斯波尔斯基 (Joel Spolsky) 描述了公司可能犯的一个最严重的战略错误。
也就是说，我们为客户完全重写了一个应用程序，这是正确的做法，因为它现在比旧应用程序更可靠、更快、具有更多功能并且更美观。从长远来看，扩展旧应用程序（多年来获得了许多功能，只是以某种方式被黑了）会更加昂贵，因为它是一个动态应用程序，每年获得一两次额外的功能。
I don't have a rule handy to decide that, but I suggest reading Things You Should Never Do, Part I, where Joel Spolsky writes about single worst strategic mistake a company can make.
That said, we completely rewrote an application for a customer, and it was the right thing to do, since it's now more reliable, faster, has more features and is more beautiful than the old one ever was. Extending the old application (which has gained a lot of features over the years that were just somehow hacked in) would have been more expensive in the long term, since it's a living application, getting additional features once or twice a year.
一般来说，我会说，如果添加功能所需的资源（时间、金钱、开发人员等）超过重写所需的资源，那么就重写。
您需要添加一些偏差，例如，重写应用程序也可能会导致将来的支持成本降低，因为许多错误将作为实现的一部分被删除，但编写新应用程序时也会出现问题（培训、进入成品的小错误、随机调试消息框或类似的垃圾）。
Generally I'd say that if the resources (time, money, developers etc) required to add the feature are more than it would take to re-write, then re-write.
You need to add some bias, for instance re-writing the application might also result in reduced support costs in the future as many of the bugs will be removed as part of the implementation, but there will also be issues when writing a new application (training, small bugs that make their way into the finished product, random debugging messageboxes or rubbish like that).
我试图不惜一切代价避免重写——有时它们是必要的，但它们总是比最初预期的麻烦得多，而且它们往往会重新引入早已在旧版本中被消除的错误。
如果业务要求你添加当前平台不支持的功能，似乎除了重写之外没有任何其他选择，但请考虑你的其他选择 - 可以通过其他方式添加功能吗？您的 Intranet 上的报告或小型 Web 部件？自动电子邮件？某种与数据库相反的网络服务？您可以通过多种方式添加功能，而无需完全废弃现有功能并接受所涉及的所有风险。
从商业角度来看，这是成本与收益的比较。如果您要添加单个功能，则需要考虑开发时间与该功能的优势。然而，如果他们想要一个需要重写的新功能，那么 8 小时的功能会突然变成 800 小时的功能（当您估计重写的开发时间时要现实一些 - “我会在下周完成”）这通常是现实的），并且业务可能不再能够证明开发时间的合理性。确保成本与收益相匹配。
I try to avoid a re-write at all costs - sometimes they're necessary, but they're always significantly more trouble than initially expected, and they tend to re-introduce bugs that have long since been squashed in the legacy version.
If the business requires that you add features that the current platform doesn't support, it may seem like don't have any other option except to re-write, but consider your other choices - can you add the functionality another way? A report or small webpart on your intranet? Automatic emails? Some kind of web service that goes against the database? There are a number of ways that you can add functionality without completely scrapping what's there and accepting all the risks that are involved.
From the business perspective, it's cost vs. benefit. If you're adding a single feature, it's dev time vs. benefit of the feature. However, if they want a single new feature that requires a rewrite, suddenly the 8 hour feature becomes an 800 hour feature (be realistic when you estimate the development time for the rewrite - "I'll do it in the next week" isn't often realistic), and the business may no longer be able to justify the development time. Make sure the cost is justified by the benefit.