> Well, if we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there. I don't think this is

> Well, if we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there. I don't think this is really incompatible with some of what Hillel gets at in his post with regards to professionalism and quality. I think it's possible for software engineers to have much higher confidence in what sorts of bugs their solutions do and do not contain, but the practice is mostly tilted towards velocity over catching every last bug. Because not all bugs are the same and not all requirements are equally important. Robust software systems are supposed to be built to minimize the impact of bugs in individual components where possible, with defensive programming techniques and such. > I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative I think this is a better candidate for a key difference than your other suggestions. We don't have a lot of good ways to apply conservative simplifying assumptions once software gets to a certain scale. We have abstractions, but where they are imperfect, any missed detail is a possible integration flaw.