I’ve worked a lot in the second environment

This was also my experience in the Nuclear Navy, wholly disconnected from software development. I was my division’s maintenance planner, among other things, and so I needed to plan when we would accomplish preventative maintenance on approximately 20 different systems. Planning was usually done a quarter at a time, but there were semi-annual, annual, and greater maintenance items you also had to take into account. Further complicating things, many of the items had specific plant criteria to be met (some are easy, like “the reactor must be shut down”), some of which would only happen once in a given quarter at best. Finally, if you wanted to maximize efficiency, you also should carefully read every maintenance item to determine where there was crossover, so you could use one to partially setup for another. I made a huge dependency table in Microsoft Project, and generated Gantt charts fro…

Estimating in the "second type of environment" is also bogus. The existence of some legal or regulatory liability doesn't really make estimations in that environment that much better. The shining example of this is Big Dig in Boston, MA: years late and 7-fold over budget. On the software side, the initial launch of Obamacare web site was a disaster. Technically not late, but severely badly designed and deployed. I know first hand that many government research (NSF, SBIR, ...) grants are chronically late or under-delivered. So I don't buy the assertion that some environments somehow make estimating any better. Humans are routinely bad at estimating, but mostly because of social and cultural reasons rather than technical or engineering reasons.

>People who have worked in the second type of environment (deadlines are real and have consequences) become quite good at estimating and managing progress toward deadlines without crunch mode at the end.< I don't know. In my experience, estimation is one of the most difficult aspects of software engineering. A black swan event or some unknown unknown will blow apart your thoughtful estimate (especially near the end of a development cycle) - no matter how good you are at it . I'd much rather have a crystal ball at hand, and let the chips fall where they may, than engage in a herculean struggle to accurately predict the future. edit:formatting

When working in an environment where there are serious consequences to being late, everyone has an easier time accepting that hard choices have to be made to get a solution out the door before the deadline. The paradigm shifts from “we want this particular solution, how long will it take?” to “we have this hard deadline, how can we solve it?”.

It cuts both ways. In my experience working in the second environment, where deadlines are arbitrary, managers and leaders do not do the work to decide what is important or what it means to “be done”. You can start out with the prior that deadlines are important and discover that there are activities that may need to be done that will blow your deadline. You can seek clarification on what should be done, but be told either of “don’t tell me the details”, “figure it out”, “I trust you to make the right decision” etc. In environments where deadlines really matter, managers are much more willing to make decisions about scope and control it closely and work with their colleagues to define a done state, because it actually matters.

> People who have worked in the second type of environment (deadlines are real and have consequences) become quite good at estimating and managing progress toward deadlines without crunch mode at the end. They become good at communicating issues with deadlines far in advance to avoid surprises. So, incentives matter - shocking, just shocking. Or maybe the take away is that is there is no incentive, someone made it up and it doesn't matter.