There's a quote in that thread that says something I've come to strongly believe over time: "Just to pick a single thing on the list, it takes at least as much

There's a quote in that thread that says something I've come to strongly believe over time: "Just to pick a single thing on the list, it takes at least as much time to analyze what a system is doing under debug. In other words, after you write the code, you spend at least as much time wondering what the system is actually doing, even if the code is nearly all correct. Starting about three years ago, I started telling folks you not only had to write code that runs correctly, you also must provide some kind of support to see whether code is running correctly. Even if there are no bugs, some emergent effect at runtime will puzzle you, and a long time can be consumed by tracing the cause and effect back to appropriate roots. When you work on a team with several other folks, after the first agonizing bug shows up, you can spend a lot of time proving your part of the system does exactly what expected, and didn't play a role in the observed chaos. Lately I seem to spend most of my time in forensic system analysis as a local coroner for other folks' code fatalities. I never had an ambition to be a code coroner. It would be enormously helpful if a language -- and not just one particular development environment -- had explicit support for generating evidence of what and how a system actually got from one point to another."