In the good old days of dial up connections and Usenet I used to enjoy a
good flame war now and then. I’m not really a flame war kind of guy. I get distracted far too easy to really commit myself to consistently flaming my enemies. And I’m bad at remembering names so in an online-world where you don’t see faces I usually forget who I’m supposed to flame anyway. But other people’s flame wars can be really entertaining.
But it seems people are slowly adapting to the way they interact online. Modern media are great for flaming but somehow I see less and less of that. You still see occasional blogosphere drama and occasionally fanboy X bashes platform Y. But that’s about it. Most people have found out that the best way to deal with trolls is to ignore them. And so people seem to find middle ground far easier. Like they should … in most cases.
People seem more and more inclined to compromise. And usually this is a good thing. Most discussions end when people agree that both points of view have their merit. Apple vs. Microsoft? Both have their sweet spot. Scrum vs. Kanban? Same there, althoug both sides seem to think their sweet spot is bigger. I’ve seen people discuss Agile vs. Waterfall and come to the conclusion that both have their place… what? wait a minute? …Waterfall? …Really?
I want to take stand right here. I never saw waterfall work! ever!
What I did see were teams that claimed to do waterfall but where actually iterating and changing requirements on the spot. Not because they didn’t want to do waterfall but because it didn’t fit their way of working. Usually this meant that after every ‘phase’ most of the documentation created was filed away and when people actually got to implementation the developers did whatever had to be done to get the job done, instead of following the outdated design.
Sometimes teams of exceptionally good developers did succeed. Not because of waterfall but in spite of it. The reason they got work done was usually because they did something resembling agile when they finally got to writing code. But without the practices to support evolving and changing requirements like TDD and fixed iteration lengths this is very hard to do.
Most of the time developers weren’t that good, quality went downhill as they tried to evolve the code and eventually the project was cancelled.
I’m prepared to seek a middle ground on many subjects but when I hear something I know is wrong expect to see flames.