These aren't hard to swallow at all - how about this: Good requirements do not exist - Writing good requirements is months of work -you have to interview bu

These aren't hard to swallow at all - how about this: Good requirements do not exist - Writing good requirements is months of work -you have to interview business stake holders, ask challanging questions, you ahve to involve industry experts and have developers think, not code. Its safe to say this almost never happens. Agile is an insidious ruse - its popular because it frees management from having to commit to planning and discovering requirements. However management still expects engineers to provide them outputs of waterfall - accurate estimates, architecture, etc. CV driven Architecture is common Engineers have a complexity addiction and feel inadequate and impotent if they are 'just building' something simple. So simple projects get bloated to inckude Kafka, kubernetes or some other buzzword of the year. Instead of discussing business problems and missing requirements, engineers prefer to discuss technical complexity. So they often commit to adding technical complexity before they've understood business complexity. Then when they hit business conolexity, they have no mental capscity or bandwidth left to address it Communication between business and Eng is usually broken To arrive at good design decisions, one person needs to have great understanding of business and technology. In most projects, this person does not exist. Design is riddled with qeustions like 'Do we really need to have feature X, it doubles complexity but only 5% of users would even care". To even understand that, business needs to communicate commercial information to developers, or developers have to educate business. This rarely happens, and so these decisions are usually not even identified