The lesson is that the system is often more than just the computer software. The requirements may be more than just the software requirements.<p>I was fortunate to recognize that early at my current job. We have boatloads of software requirements documented, but the prime directive is not even spoken aloud: "Produce 40 billable hours per week, for each employee, forever."<p>And that is why the database is a mess and the code sucks beyond all reason. Any reduction in technical debt directly translates to a reduction in the perception of work being done. In short, the customer knows nearly nothing about software development, is willing to pay for status reports, process documentation, and meeting minutes rather than working code, and has a budget completely independent from the value of the work product.<p>Have you ever looked into some code and seen a WTF block, and it turned out to be a workaround for a bizarre bug? Here, the entire code base is the WTF block. The bug is in the human organization. I do not have the permissions to commit anything to that source tree. So I suck it up and send out resumes.<p>You don't fix <i>anything</i> until you first understand why it is broken. In the context of the CAD rendering, it is likely that some people had invested a lot of effort into convincing the management that their laziness was actually hard work plus frustration at their resource constraints. Think like Wally from Dilbert. That slow rendering is a system-enforced cap on productivity, slowing down the fastest workers.<p>In the psycho-clueless-loser model, that is the losers getting a leg up on the clueless. A psycho would have first manipulated the political situation for personal advantage before releasing the fixed code. A loser would have left it alone as already being to their advantage. Don't be clueless, folks.