There's a lot to hate in this sort of passive-aggressive yet obsequious stance of project management. It is akin to the Agile practice of nailing notecards to a

There's a lot to hate in this sort of passive-aggressive yet obsequious stance of project management. It is akin to the Agile practice of nailing notecards to a wall, and then forcing a territorial pissing battle carried out on that same wall later. It doesn't matter what is on the wall, but the surface area must remain the same, relative to some maximum achievable surface area metric we scoped out somewhere else, presuming ourselves to be perfect at knowing how long things will take. It all seems so amazingly childish to me. But I'm not surprised; ask anyone from either party battling it out on the wall, and the response will be about as substantive as "they're such whiny little babies, and I need to cover my ass from their inevitable fuck-ups". So we force on them responsibility in the most condescendingly smarmy way possible, by recognizing and granting weight to their authority while at the same time sneering at it and throwing them binary decisions, as though that was the real problem. The real problem is culture, not features. Only a small part of the rant the original author wrote was about the features of the product he was developing. A good portion about it was about a culture that didn't give a shit about everything else in code except the features; organization, readability, maintainability, and everything else don't matter. They knew full well that this was not a "throwaway" product based on the objectives they laid out, but used "throwaway" like this magic word that had no prerequisites, and was just a synonym for "finish it faster". They could've asked for neither feature, and I would bet code would've still sucked, because developing maintainable code is far more difficult than slapping together a roughed-out, buggy first pass. But the culture believed as a tenet that maintainable code was not important; and that belief is probably about as easy to scour out as the outlandish beliefs of political pundits. Adopting an attitude of defensive compliance would only make the culture within more vulnerable to bullshit like this. The culture was already based on childishness, and behaving like a child would add more validation to the culture. Bare in mind it's not the tone of the defensiveness I am calling childish, it is the content. The template response quoted by patio11 is just as childish, even if you imagine it spoken in a professonal, dignified tone. It deflects responsibility by way of establishing a very polarized power relationship between boss and subordinate, to where those words do not sound at all out of place. It is Bad Agile in spades.[1] This sort of power relationship makes a lot of very important conversations that need to take place within a software project much more difficult and less likely. These aren't the conversations to do with culling or amending the feature set. They are the conversations to do with trade-offs based on the same feature set; they are matters to which the developers, and not the management, have the most knowledge and insight. But they can't happen when people believe that important decisions happen only certain places within an organization. It was brought up elsewhere in this thread by patio11, and so I'll take a bit of latitude to say now that Japanese salaryman culture, and for that matter the bad facsimile of salaryman culture that American corporations seem to have adopted, is an extremely toxic environment for getting software written -- neverminding all the other things it is extremely toxic. It is a culture built on defensiveness and evasion of even the faintest whiff of responsibility for anything that requires any sort of discretion. I think that it is this culture that is the fundamental problem, and that we keep trying to cure the disease by treating the symptoms. Salaryman culture doesn't even work perfectly for manufacturing, where there is literally no discretion amongst the rank-and-file. Things still go badly: the car still has brakes that fail, the toy still contains toxic amounts of lead, the plant still leaked toxins into the river nearby. How the hell do we expect it to work for something as obviously based on almost continuous acts of discretion like software development? This culture is broken, and we need to stop tacitly accepting that brokenness is inevitable and perpetual. Or have we just decided the cultural battle is lost, and that we have to settle with whatever symbolic victories we can get to get through the day? [1] The idea of Bad Agile is discussed more here: http://steve-yegge.blogspot.com/2006_09_01_archive.html http://steve-yegge.blogspot.com/2006_09_01_archive.html