You only have three knobs you can turn when shipping software, assuming a fixed number of developers: features, quality and ship date, and turning one up means the others get turned down.
One of the most difficult things to do in software development is to build your product with the knobs set just right. For example, the Duke Nukem Forever guys have turned the features and quality knob up to eleven and thrown the ship date knob out the window. Microsoft often seems to glue the ship date knob in place and turn down the feature knob as needed, then unglue the ship date knob, turn it up a bit, glue it back down and continue twiddling the other two. And there are seem to be an endless amount of products out there that ship all the time but never put in the features they need to be successful.
In the end, you don't get paid if you don't deliver. Having poor quality hurts you terribly in the long run; reputations are hard to rebuild. It has almost always been that the right thing to do is to cut features if you have too many bugs. Always.
However, bug triage is just as important as feature development. What kind of leak are we talking about here? Are you leaking a byte? A small object? One thousand objects? Entire DLLs? There are scenarios where its probably better to leak a little than to fail to deliver the product.
And what do you mean by leak? Does your application have a well defined life cycle? Where you allocate something once at startup and then never free it until the process dies? Well how long does your process run? Do you expect to run multiple copies of your process?
Obviously you never want to leak, and you should work to develop best practices that minimize leaking, but in the end you have to make a judgment call. Maybe you can just explain the bug to your customers, explain the impact, and they'll buy it anyway. Maybe you can patch it a week later. Maybe you really do need to fix it. But we'd need to know more about it to give good advice.
I will say I have shipped known leaks in the past. I won't say what product or company, but I had a bug where DLL dependencies and insane lifetime management made it next to impossible to correctly free our references to a certain DLL once it was loaded, so in the end we just leaked it. And I still think it was the right thing to do. Other times I've seen things deliberately leaked to keep third party code that was written incorrectly from crashing (though that is a completely separate debate).
But in the end I believe such instances are rare and once you have identified the source of a memory leak, it shouldn't take much more than a day to fix it. It is rare indeed that I would ship with a memory leak that was known and a fix was known. It would have to be something that required a major re-architect involving changing a threading model, or refactoring huge swaths of code, and it would literally have to be a day or two before the product was to ship. At that point I might just leak the memory and promise a patch in a weak after proper testing could be done on the re-architect.
Perhaps, when you are not going to be around to maintain the code later, you don't care about your client/employer and none of the ramifications of your code could possibly affect you.
In other words, in your professional coding life, it's never a really good idea.
If you are working for someone that is less concerned about code quality than you are and simply wants you to finish the code at all costs, then I can see how you'd be in a difficult situation. Finishing faster but poorer will earn you some immediate reward. You should remember though that even if failing to meet your employer/client's expectation for a milestone bites you only once, your poor code may continue to bite you into the future, not only through the difficulties in maintaining it but also through the negative impression others may form of you down the track.
If its a single (or limited) memory leak, and it doesn't grow, and say it only causes a crash when shutting down (the most common case of stuff like this), then it depends. If its a client/desktop software and the users are going to crash every time on their way out, I'd make it an ultra high priority. If its server, and the only one running the server is you, and everything else works fine, I'd say its alright to enter beta. But if the leaks grow, or can cause crashes at "random" times they need to be fixed asap.
To get past an internal milestone, it's arguable, although still nothing to be taken likely.
To release, never. It always comes back and bites you. If your software is in such a bad space that a piece of poor design will get it over the line, you've got much bigger problems looming round the corner
Ultimately, a decision like this should be made by the customer or the project manager. Individual developers should not be making these kinds of decisions alone, or keeping this information to themselves.
Tell them what the problem is, and what the consequences will be for not fixing it. If they want you to ship it broken on time, that's their call.
If you don't want to work for people who accept shoddy products, that's your call, but it's a mistake to think that developers have some sort of professional responsibility to ignore their clients' and bosses' quality/cost/time priorities.
If somebody may actually die if you ship bad software, then don't do it, but if the worst-case scenario is that somebody is going to have to reboot a couple times per day, then do what you're told or find another job.
If the problem's impact on actual usage of the system can be reasonably expected to be none or negligible, and the delivery date cannot be pushed back, and it can be fixed within a scope of time before the problem's impact becomes more than negligible, ship it.
Obviously this is not ideal or even recommended, but you're clearly pushed into a corner at this point. Sometimes there are no good choices, but pragmatism must win over formal correctness. If an application has a memory leak, but we can reasonably expect that the app will be recycled or machine restarted or whatever before the leak becomes a real problem, that can sometimes be better than delivering late. It depends on the conditions of the agreement and the customer.
It's always better to at least try to push back the delivery date, but I am assuming you've already tried that and it's not an option here.
It is typical once an application has been shipped to ignore technical debt and move on. It's the responsibility of the developers to clearly communicate to the stakeholders the importance of paying off some of that debt, especially in a case like this.
However, given that it seems the customer cares more about a delivery date than correctness, it's less likely anyone will be convinced to pay off any debt once you go live. This is a bad situation to be in. Only the person with all the facts can make the right choice.
My question is, when do you decide to deliver code in this state, if it's not possible to release code without these poor practices, in time?
Never.
What you do instead: prioritize and focus.
If what you're working on is really high-priority, and you've mis-designed it, something low- priority has to be sacrificed. Often, some feature(s) must be delayed to give you time to focus on the high priority feature that doesn't work.
If what you're working on is really low-priority, you have to ask why you're not working on something higher-priority. And you still have to focus and prioritize. Sometimes things which are very low priority must be sacrificed.
When you can't do "everything" you have to pick things you can do that will be reasonably bug-free.
发布评论
评论（10）
您可能对技术债务的概念感兴趣。
You might be interested in the concept of technical debt.
假设开发人员数量固定，在交付软件时您只能转动三个旋钮：功能、质量和交付日期，转动其中一个就意味着其他人会被拒绝。
软件开发中最困难的事情之一就是用正确的旋钮来构建你的产品。 例如，《永远的毁灭公爵》的开发人员已将功能和质量旋钮调至 11，并将发货日期旋钮扔出了窗外。 微软似乎经常将发货日期旋钮粘在适当的位置，并根据需要调低功能旋钮，然后松开发货日期旋钮，将其调高一点，将其粘回原处，然后继续摆弄其他两个旋钮。 似乎有无数的产品一直在发货，但从未添加成功所需的功能。
最后，如果你不交付，你就得不到报酬。 从长远来看，质量差会对你造成严重伤害； 声誉很难重建。 如果错误太多，几乎总是正确的做法是削减功能。 总是。
然而，错误分类与功能开发同样重要。 我们在这里谈论什么样的泄漏？ 你泄漏了一个字节吗？ 一个小物体？ 一千个物体？ 整个DLL？ 在某些情况下，泄漏一点可能比无法交付产品更好。
泄漏是什么意思？ 您的应用程序有明确定义的生命周期吗？ 你在启动时分配了一次东西，然后在进程终止之前永远不会释放它？ 那么您的流程运行多长时间？ 您希望运行流程的多个副本吗？
显然，您永远想要泄漏，并且您应该努力开发尽量减少泄漏的最佳实践，但最终您必须做出判断。 也许您只需向客户解释该错误，解释其影响，他们无论如何都会购买。 也许一周后你可以修补它。 也许你确实需要修复它。 但我们需要更多地了解它才能提供好的建议。
我会说我过去曾发布过已知的泄漏信息。 我不会说是什么产品或公司，但我遇到了一个错误，DLL 依赖项和疯狂的生命周期管理使得我们在加载某个 DLL 后几乎不可能正确释放对它的引用，所以最终我们只是泄露了它。 我仍然认为这是正确的做法。 其他时候，我看到故意泄露一些东西，以防止编写不正确的第三方代码崩溃（尽管这是一个完全独立的争论）。
但最终我相信这种情况很少见，一旦确定了内存泄漏的根源，修复它的时间不会超过一天。 事实上，我很少会附带已知的内存泄漏并且已知修复方法。 它必须需要进行重大的重新架构，涉及更改线程模型或重构大量代码，并且实际上必须在产品发布前一两天。 到那时，我可能会泄漏内存，并承诺在重新架构上进行适当的测试后，在弱中提供补丁。
You only have three knobs you can turn when shipping software, assuming a fixed number of developers: features, quality and ship date, and turning one up means the others get turned down.
One of the most difficult things to do in software development is to build your product with the knobs set just right. For example, the Duke Nukem Forever guys have turned the features and quality knob up to eleven and thrown the ship date knob out the window. Microsoft often seems to glue the ship date knob in place and turn down the feature knob as needed, then unglue the ship date knob, turn it up a bit, glue it back down and continue twiddling the other two. And there are seem to be an endless amount of products out there that ship all the time but never put in the features they need to be successful.
In the end, you don't get paid if you don't deliver. Having poor quality hurts you terribly in the long run; reputations are hard to rebuild. It has almost always been that the right thing to do is to cut features if you have too many bugs. Always.
However, bug triage is just as important as feature development. What kind of leak are we talking about here? Are you leaking a byte? A small object? One thousand objects? Entire DLLs? There are scenarios where its probably better to leak a little than to fail to deliver the product.
And what do you mean by leak? Does your application have a well defined life cycle? Where you allocate something once at startup and then never free it until the process dies? Well how long does your process run? Do you expect to run multiple copies of your process?
Obviously you never want to leak, and you should work to develop best practices that minimize leaking, but in the end you have to make a judgment call. Maybe you can just explain the bug to your customers, explain the impact, and they'll buy it anyway. Maybe you can patch it a week later. Maybe you really do need to fix it. But we'd need to know more about it to give good advice.
I will say I have shipped known leaks in the past. I won't say what product or company, but I had a bug where DLL dependencies and insane lifetime management made it next to impossible to correctly free our references to a certain DLL once it was loaded, so in the end we just leaked it. And I still think it was the right thing to do. Other times I've seen things deliberately leaked to keep third party code that was written incorrectly from crashing (though that is a completely separate debate).
But in the end I believe such instances are rare and once you have identified the source of a memory leak, it shouldn't take much more than a day to fix it. It is rare indeed that I would ship with a memory leak that was known and a fix was known. It would have to be something that required a major re-architect involving changing a threading model, or refactoring huge swaths of code, and it would literally have to be a day or two before the product was to ship. At that point I might just leak the memory and promise a patch in a weak after proper testing could be done on the re-architect.
如果发布这样一个已知的错误，我会感到非常不舒服。 它很可能以另一种方式发生。
您尚未指定您的环境或语言，但我建议您使用内存检查工具，例如：
Purify（可试用）
BoundsChecker
Valgrind
甚至是免费的，视觉检漏仪
I would be very uncomfortable releasing with such a known bug. It is likely to occur in another way.
You have not specified your environment or language, but I suggest you look at using a memory checking tool such as:
Purify (trial available)
BoundsChecker
Valgrind
or even a free one, Visual Leak Detector
也许，当您以后不再维护代码时，您不关心您的客户/雇主，并且代码的任何后果都不会影响您。
换句话说，在你的职业编码生涯中，这从来都不是一个真正的好主意。
如果你的工作人员不像你那样关心代码质量，只是希望你不惜一切代价完成代码，那么我可以想象你会陷入多么困难的境地。 完成得更快但更差会给你带来一些直接的奖励。 但你应该记住，即使未能满足雇主/客户对里程碑的期望只会让你痛苦一次，你糟糕的代码可能会在未来继续困扰你，不仅因为维护它的困难，而且还因为其他人的负面印象可能会让你走上正轨。
Perhaps, when you are not going to be around to maintain the code later, you don't care about your client/employer and none of the ramifications of your code could possibly affect you.
In other words, in your professional coding life, it's never a really good idea.
If you are working for someone that is less concerned about code quality than you are and simply wants you to finish the code at all costs, then I can see how you'd be in a difficult situation. Finishing faster but poorer will earn you some immediate reward. You should remember though that even if failing to meet your employer/client's expectation for a milestone bites you only once, your poor code may continue to bite you into the future, not only through the difficulties in maintaining it but also through the negative impression others may form of you down the track.
如果它是单个（或有限的）内存泄漏，并且它不会增长，并且说它只会在关闭时导致崩溃（此类情况最常见的情况），那么这取决于。 如果它是一个客户端/桌面软件，并且用户每次退出时都会崩溃，那么我会将其列为超高优先级。 如果它的服务器，并且唯一运行该服务器的人是你，并且其他一切正常，我会说进入测试版是可以的。 但如果泄漏增加，或者可能在“随机”时间导致崩溃，则需要尽快修复。
If its a single (or limited) memory leak, and it doesn't grow, and say it only causes a crash when shutting down (the most common case of stuff like this), then it depends. If its a client/desktop software and the users are going to crash every time on their way out, I'd make it an ultra high priority. If its server, and the only one running the server is you, and everything else works fine, I'd say its alright to enter beta. But if the leaks grow, or can cause crashes at "random" times they need to be fixed asap.
要超越内部里程碑，这是有争议的，尽管仍然没有什么可采取的。
要释放，永远不要。 它总是会回来咬你。 如果您的软件处于如此糟糕的空间，以至于一个糟糕的设计就会让它越线，那么您就会遇到更大的问题迫在眉睫
To get past an internal milestone, it's arguable, although still nothing to be taken likely.
To release, never. It always comes back and bites you. If your software is in such a bad space that a piece of poor design will get it over the line, you've got much bigger problems looming round the corner
永远，除非您不关心之后将维护您的工作的可怜的开发人员。
Never, unless you don't care about the poor developer who is going to be maintaining your work afterwards.
最终，这样的决定应该由客户或项目经理做出。 个人开发人员不应单独做出此类决定，也不应将这些信息保密。
告诉他们问题是什么，以及不解决问题会产生什么后果。 如果他们希望您按时运送破损的货物，那是他们的决定。
如果您不想为接受劣质产品的人工作，那是您的决定，但认为开发人员有某种职业责任而忽视客户和老板的质量/成本/时间优先事项的想法是错误的。
如果如果你发布了糟糕的软件，某人实际上可能会死，那么就不要这样做，但如果最坏的情况是某人每天必须重新启动几次，那么就按照你所说的去做，或者找到另一个工作。
Ultimately, a decision like this should be made by the customer or the project manager. Individual developers should not be making these kinds of decisions alone, or keeping this information to themselves.
Tell them what the problem is, and what the consequences will be for not fixing it. If they want you to ship it broken on time, that's their call.
If you don't want to work for people who accept shoddy products, that's your call, but it's a mistake to think that developers have some sort of professional responsibility to ignore their clients' and bosses' quality/cost/time priorities.
If somebody may actually die if you ship bad software, then don't do it, but if the worst-case scenario is that somebody is going to have to reboot a couple times per day, then do what you're told or find another job.
如果可以合理预期该问题对系统实际使用的影响不会或可以忽略不计，并且交付日期无法推迟，并且可以在问题影响变得可忽略不计之前的一段时间内修复，则发货。
显然这并不理想，甚至不推荐，但此时您显然已被逼到了角落。 有时没有好的选择，但实用主义必须战胜形式正确性。 如果应用程序存在内存泄漏，但我们可以合理地预期应用程序将被回收或机器重新启动或在泄漏成为真正问题之前进行任何操作，有时这比延迟交付更好。 这取决于协议和客户的条件。
至少尝试推迟交货日期总是更好，但我假设您已经尝试过，但这里不可行。
通常，一旦应用程序交付，就会忽略技术债务并继续前进。 开发商有责任向利益相关者清楚地传达偿还部分债务的重要性，尤其是在这种情况下。
然而，考虑到客户似乎更关心交货日期而不是正确性，一旦上线，就不太可能有人会被说服还清任何债务。 这是一个糟糕的情况。只有了解所有事实的人才能做出正确的选择。
If the problem's impact on actual usage of the system can be reasonably expected to be none or negligible, and the delivery date cannot be pushed back, and it can be fixed within a scope of time before the problem's impact becomes more than negligible, ship it.
Obviously this is not ideal or even recommended, but you're clearly pushed into a corner at this point. Sometimes there are no good choices, but pragmatism must win over formal correctness. If an application has a memory leak, but we can reasonably expect that the app will be recycled or machine restarted or whatever before the leak becomes a real problem, that can sometimes be better than delivering late. It depends on the conditions of the agreement and the customer.
It's always better to at least try to push back the delivery date, but I am assuming you've already tried that and it's not an option here.
It is typical once an application has been shipped to ignore technical debt and move on. It's the responsibility of the developers to clearly communicate to the stakeholders the importance of paying off some of that debt, especially in a case like this.
However, given that it seems the customer cares more about a delivery date than correctness, it's less likely anyone will be convinced to pay off any debt once you go live. This is a bad situation to be in. Only the person with all the facts can make the right choice.
绝不。
相反，你应该做什么：优先考虑并集中精力。
如果你正在做的事情确实是高优先级的，而你设计错误，那么就必须牺牲一些低优先级的事情。 通常，某些功能必须延迟，以便您有时间专注于不起作用的高优先级功能。
如果你正在做的事情确实是低优先级的，你必须问为什么你不做更高优先级的事情。 而且你仍然必须集中注意力并确定优先顺序。 有时必须牺牲优先级非常低的事情。
当您无法完成“所有事情”时，您必须选择您可以做的事情，并且这些事情不会出现任何错误。
Never.
What you do instead: prioritize and focus.
If what you're working on is really high-priority, and you've mis-designed it, something low- priority has to be sacrificed. Often, some feature(s) must be delayed to give you time to focus on the high priority feature that doesn't work.
If what you're working on is really low-priority, you have to ask why you're not working on something higher-priority. And you still have to focus and prioritize. Sometimes things which are very low priority must be sacrificed.
When you can't do "everything" you have to pick things you can do that will be reasonably bug-free.