Agree. Truly bad software is going to be bad for the business. Software that grows more complex is rendered that much less adaptable to changing requirements, r

Agree. Truly bad software is going to be bad for the business. Software that grows more complex is rendered that much less adaptable to changing requirements, requiring more resources for its adaption. I accept that some employers and managers do not understand that reality, that maintenance can benefit adaptability and upfront work can create a better starting point that ultimately benefits the business as a whole by enabling more efficient execution. However, there is also the danger of having an engineer who is mired in trying to achieve some (often incoherent or misguided) state of perfection, guided by a religious commitment to an unspecified measure of "best", paralyzed by the sheer number of ways something could be improved in some conceivable way. He risks living in a bubble, disconnected from the larger goal and reality the software he is working on is a part of. This disconnect results in bad prioritization and little grasp of trade-offs. The idea of "long-term planning" is also problematic because, taken too far, can become an exercise in speculation and fortune-telling. As Woody Allen said, if you want to make God laugh, tell him your plans. You can aim in a general direction, but expect course correction. There is no "once-and-for-all". Effective engineering requires prudence. Mature and seasoned engineers are better able to distinguish actual needs from possible needs or wants, make decisions and prioritize work based on the limited resources they have. There are programming techniques and approaches (if not wholesale methodologies) that are motivated by this wisdom and that enable an engineer to manage the evolution of his software. Between the extremes, there is a range of reasonable opinion and approaches. To me, it sounds like the author is either working in an exceptionally bad company or suffers from OCD.