> If you really have a fleet of web servers burning CPU and you aren't tracking the costs, then I guess "it works" until someone figures out there isn't any mon

> If you really have a fleet of web servers burning CPU and you aren't tracking the costs, then I guess "it works" until someone figures out there isn't any money left in the coffer. What if the costs are fixed? (own servers, unmetered bandwidth) The problem shifts down the line when you want to add a new product and the first product is consuming all your resources. Refactoring then becomes a necessity, but there's no capacity for it because the company is focused on shiny product #2, while also adding shiny features to product #1. Now fire a few people to save money, leaving the remainder short handed, who get stressed and demoralised. But that's ok, because "it works!". Why cant we design first, lay down a good foundation, then add features. The business makes more money, people keep their jobs, instead of spit-balling "user stories" at an application which becomes a giant spit-ball. > CPU efficiency isn't the be-all to end-all and focusing on it may well prove to be counter productive > You can spend a near infinite amount of time & resources trying to get optimal performance I used CPU as a broad example. What happened in my case was there was no performance. At release it was unusable. What stuck in my side was I knew it was going to happen, and had been calling for refactors. But if you cant get them prioritised because you cant justify the customer benefit (it's not released yet, so nothing has fallen over yet) vs features! features! features! it then becomes a bodge job /after/ release. eg. Instead of "refactor this code to make it do fewer queries" it's "lets shove the results of these queries into a memory cache." This satisfies agile, you've iterated and made things "better" - and it fit into a 2 week sprint! - but it feels backwards. I was going to go on and talk about quantity vs quality, but a quick fact-check google revealed the evangelists with their "Agile parables" (it even sounds cultish), which are in no way perpetuating Agile to sell support tools, say I'm wrong. I need to thank you for making me realise it's time for a career change. After all this time Agile has failed to convince me, I'm inclined to conclude it never will. But should the next methodology of the moment come along that emphasises quality over quantity, I reserve the right to shout "I told you so!"