Happpy with What You Have to be Happy With

Recently, I did a 3-hour tutorial workshop at the SOA conference in Singapore entitled "Agile Development and SOA", where I talked about aspects of Agile development as it applies to SOA type projects. Mostly, it was an excuse to talk about Agility in a foreign land.

I asked the attendees what type of methodology they were currently using. The three replies I got were 1. None (what's a methodology?), 2. Waterfall (although she didn't know that name for it), and 3. SDLC (the Software Development Lifecycle (another variant of Waterfall, check out this interesting Wikipedia image of SDLC )). So, basically, everyone is using some form of Waterfall. What's interesting is that I asked to most vocal of the crowd (meaning that she would actually answer without me jumping up and down on the table in front of her -- she was the SDLC victim) if her company was happy with that methodology. She quickly replied "Oh, yes, it works very well for us". Needless to say, I was surprised. So I asked her a few follow-up questions:

• Do you ever miss deadlines? Oh, yes


• Are your user's happy with what you produce? Well, no


• Are your developers frustrated by vague requirements, which leads to user dissatisfaction? Yes


• Do you ever accidentally break code in your "big bang" deployments, which takes a long time to fix? Yes

I asked a few more, but you get the gist. She thought they were very happy with SDLC because they didn't know that something better existed. Perfect crowd for an agility talk, right? It was an uphill battle. No one could believe that this crazy idea could ever work -- waste all that time writing tests? Include the users as part of the development team? Pair Program?!? That cuts your productivity in half! Sigh. I waged a good battle, but don't know how well the war is going. At the end of the talk, I had either convinced them to tip-toe towards Agility (because these were developers -- can you imagine what their boss will say?) or they were just tired of me talking about it and said anything to get me to shut up.

I've blogged about this phenomenon before -- why is it that developers and managers believe that all forward progress in methodology stopped in the mid-70's and all language development froze about the time Objects appeared? Is it just a non-technical person's fatigue at trying to keep up, so an arbitrary milestone was created beyond which "I won't think about it anymore?" Are developers so overwhelmed that they just shut down too, and keep working on what's in front of them even though better things abound?