Estimates aren't so much of a concern for me as quality.<p>While bridges can fail after 50 years, the general state of many software applications (particularly in enterprise software) is seemingly less good.<p>I primary issue is lack of standardization and rigor in the field that allows for quantifying allowable defects, test coverage requirements, and understanding of failure scenarios. Simply put, so much is played very fast and
loose. Fragile systems are sometimes built in haste on fragile foundations.<p>In say, electrical and building codes for houses (not engineering so much, but applicable), there are established standards for protection of consumers and standardization of work. In software, usually these don't exist - or they exist in small legal areas like PCI or HIPAA, and don't really explain how the software is built either, but only some of the properties. Not only do building codes exist, but the similar codes and standards exist for the parts the technicians install.<p>Rather than codify the practices of the craft that firm things up, everybody's still trying to figure out what those practices are. And maybe that's ok. Bridge building has been done for thousands of years, and software has been done for far less than a century.<p>We are still figuring a lot out. Yet, at the same time, I don't think we remember much from history, software that has "nailed it", and analyze what works and doesn't.<p>Software is also kind of not engineering because it's an expressive medium to some, kind of an art, hence the application of "craftsmanship" frequently applied. We are sometimes inventors, sometimes engineers, sometimes sometimes carpenters, sometimes plumbers.<p>These are all valid fields, but I do want for greater engineering rigor over the long haul. I think it would make things less stressful. But right now, we (as the people in the industry) are doing all these breadth first forays to figure out how software is built - sometimes getting stuck in local minima and maxima until we can upset an ideology enough to try something new - and that's partly why it feels like it does. We have a lot of people with different experience levels and different specializations, and often conflicting opinions, where sometimes none are clearly right or wrong.<p>On the other end, business also needs to change. A bridge is never "sold quickly", it is sold and then takes as long as it takes. Electronics can be pitched heavily, but the cost of field replacement is so remarkably large it must be gotten right the first time. However, software can quickly be replaced on the fly. More so a problem if you are working on a .com than on firmware, the need for rigor is reduced and engineering deliverable is more controllable by the desires of the business side.<p>Ultimately, it's still a remarkably new industry, and it itself is able to evolve quickly, as we are not realing dealing with the rules of chemistry, but rather conceptual ideas and logic. Logic and ideas are fuzzy complicated beasts.