Do it if you want but in all my years I've never seen a company sunk by a missed deadline. At best it's a minor set back. At worst checks get delayed or contrac

Do it if you want but in all my years I've never seen a company sunk by a missed deadline. At best it's a minor set back. At worst checks get delayed or contracts terminated. Maybe that's enough to sink your tiny startup when you're first starting out. For most companies that have made it past their first year it's not the end of the world. Empirical studies on the causes of errors, delays, etc in software projects of different stripes and knowledge work in general suggest that stress and sleep are the most important factors [0]. In video games deadlines are paramount and yet, ironically, crunch as the systemic form of over-work has become known correlates strongly with review scores and sales: the more a team is forced into meeting these arbitrary deadlines the lower the review scores and overall sales of the game [1]. I don't think this is unique to the games industry. I've seen enterprise development shops put in crunch time to meet customer driven deadlines agreed to by the sales teams with similar results: developers burn out and leave the company, tech debt runs rampant, and customers get frustrated. The article doesn't touch on the different kinds of projects one may be asked to give estimates for. A speculative project shouldn't be estimated. This is where the team doesn't have the skills required or has never shipped any software with a similar scope or feature set. There are so many unknowns between where you are and the end goal that an estimate is only a dangerous guess. The only way you can make an accurate estimate is to begin work and get close to the goal. Some where between starting and finishing you will have enough information to make an informed and reasonably confident estimate. Along with good release planning this can be a relatively low-stress process. Estimates at the beginning of the project create poor expectations and can lead to stress. The enemy of a good plan is a perfect one. Stress is so bad that it won't matter, much, that you do code review or have automated CI and CD gates and checks. Your engineering team will simply not be as effective as a team that isn't stressed or tired. Anything you can do to keep your team from being stressed out or tired is going to translate into better outcomes. If that means relaxing on deadlines and focus more on results and progress than do that instead. One thing I can agree with is that communication is key. And a good night's sleep. [0] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2656292/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2656292/ [1] https://gamasutra.com/blogs/PaulTozour/20150120/234443/The_Game_Outcomes_Project_Part_4_Crunch_Makes_Games_Worse.php https://gamasutra.com/blogs/PaulTozour/20150120/234443/The_G...