Most software out there follows the "Big Ball of Mud" [1] essay almost verbatim. My (anecdotal) rule of thumb is that after around 10 years of this kind of deve

Most software out there follows the "Big Ball of Mud" [1] essay almost verbatim. My (anecdotal) rule of thumb is that after around 10 years of this kind of development, the inefficiency grows so big that development stalls. That happens when the ratio of new features to new breakages approaches one. Then the company adds more and more developers to work on the same codebase, which will not help because their productivity will be super-slow. Instead they should be working in rebuilding the product. Of course, at some point doing a huge design and making everything technically perfect from the beginning is wasteful. The main mistake to me, however, is not realizing the long-term costs and that doing it "right" is not so expensive. One does not even need to design everything, just have enough foresight to not paint oneself into a corner design-wise. [1] http://www.laputan.org/mud/mud.html http://www.laputan.org/mud/mud.html