I’m not sure I follow how you came to that conclusion. I think their point is, paraphrased, spaghetti code that meets the requirements, schedule and budget is b

I’m not sure I follow how you came to that conclusion. I think their point is, paraphrased, spaghetti code that meets the requirements, schedule and budget is better than pretty code that functions, but does not meet one or more of the aforementioned. That’s not to say that only spaghetti code can make a good project, but to illustrate the point. Sure, sometimes everything works out where you can refine something to the point where it’s a golden (or near perfect) solution, but any solution that meets business requirement x is better than one that does not at all. I’m not sure if it really comes down to this, but my standards for internal tools are much higher than things developed on the customer facing side. I think I mostly attribute that to the fact that we know how to successfully develop our user/business requirements versus our customers who do not. Hell, I have customers who have asked us to write their requirements. That’s a huge red flag for an unsuccessful solution.