How to Build Good Software
Nice Post. But everyone needs to understand something. Even if you follow these principles to the letter T, you can still produce very bad software. In fact you can also find many cases where people did the exact opposite of what this guy said and still produced great software. I&#x27;m sure many people can name examples of software that just came together out of blind luck.<p>Why?<p>Because there is no formal definition for what is bad or good software. Nobody knows exactly why software gets bad or why software gets good or what it even exactly is... It&#x27;s like predicting the weather. The interacting variables form a movement so complex that it is somewhat impossible to predict with 100% accuracy.<p>What you&#x27;re reading from this guy is the classic anecdotal post of design opinions that you literally can get from thousands of other websites. I&#x27;m seriously tired of reading this stuff year over year rehashing the same BS over and over again, yet still seeing most software inevitably become bloated and harder to work with over time.<p>What I want to see is a formal theory of software design and by formal I mean mathematically formal. A axiomatic theory that tells me definitively the consequences of a certain design. An algorithm that when applied to a formal model produces a better model.<p>We have ways to formally prove a program 100% correct negating the need for unit tests, but do we have a formal theory on how to modularize code and design things so that they are future proof and remain flexible and understandable to future programmers? No we don&#x27;t. Can we develop such a theory? I think it&#x27;s possible.