It has been a whirlwind week for me. Products launching to hundreds of millions of users have required quite a bit of focused attention. It feels good to have them going smoothly and I look forward to the reaction from people at CES. So, in my own neck of the woods I have several posts ready to go for the prior days, but have not had enough time to edit them for release. I might be able to squeeze them out today, but it begs the question if I should back-date them to when the bulk of them were written, or date them for today’s launch to the public?

I noticed a related story about code-complete and deadline launch dilemmas written-up on Stevey’s Blog Rants. He attempts to discuss the nature of human behavior and how it can impact quality as well as timing.

Up until maybe a year ago, I had a pretty one-dimensional view of so-called “Agile” programming, namely that it’s an idiotic fad-diet of a marketing scam making the rounds as yet another technological virus implanting itself in naive programmers who’ve never read “No Silver Bullet”, the kinds of programmers who buy extended warranties and self-help books and believe their bosses genuinely care about them as people, the kinds of programmers who attend conferences to make friends and who don’t know how to avoid eye contact with leaflet-waving fanatics in airports and who believe writing shit on index cards will suddenly make software development easier.

You know. Chumps. That’s the word I’m looking for. My bad-cholesterol view was that Agile Methodologies are for chumps.

The fatal flaw in this blogger’s rant is the horribly weak analysis that follows from the above (e.g. if you shower developers with simple incentives it will invariably result in higher quality, as if incentives were easy to understand let alone justly distribute). In other words, he acknowledges that human behavior is a risk, but then fails to understand human behavior and instead faults the system they are using as if Agile is to blame for failing to correct all engineering practices. Nonetheless, after I managed to read through its entirety I had to laugh at the fact that he says he can find no way to tell good cholesterol from bad before he burns through several hundred rambling lines in an attempt to explain *simply* that it shoud be obvious to even the casual programmer how to know good from bad Agile.

The bottom line for Stevey appears to be that he likes to eat, and if you feed him good food (since he admits at the start he can’t figure out the risks for himself) then he will perform well. This is a fine model for the great Stevey, but hardly the stuff a project or risk manager can apply more universally. He might as well say something like wearing brown shoes and a blue shirt works best in his experience therefore others should try it too. Systems are prone to failure; there are many risks. But that does not mean that a system can never be successful, or at least average out with more wins than losses. And with that said, I plan on back-dating my posts to give myself credit for having written them, even if the editing was not complete until today.