Software Project Management: "Releases" are Stupid and Out-moded

Tell me, do you use Google by any chance? Yes? OK, now tell me which release of Google you use now, which ones you've used recently, and which one you like best; and, by the way, how was the upgrade process? Oh, you don't know? There's no way to find out, you say?

What the heck is WRONG with those people at Google? Don't they know that modern software development processes demand a disciplined release and planning methodology? There is NO WAY customers will put up with a product when the vendor just shoves new releases at them any time they feel like it, without even proper notification! And what customer is going to sign up with a vendor who won't commit to a future roadmap, with at least a year's worth of features laid out, tied to hard-commit release dates? That Google, they violate every rule of the game, there's no way they're going to make it as a software/service company!

What, how can it be! NOOOOoooooo.... Google is the world's most valuable software company!!?? When they don't even have the most basic element of proper software methodology, releases?? I must be sleeping! This must be a nightmare!!

Get over it!

Here are the facts:

• Classic project management has been a disaster for software development.
• All the heavy-weight process things that people do to make things better ... invariably makes them worse!
• The classic big-bang release is the cornerstone of the temple of evil.
• The classic little-bang release (a.k.a. "agile") is a brick in the temple of evil.
• "Releases" are ... stupid! ... and not only that, they're ... outmoded!

 There is life after "releases." It is a better life. The software is better. The users are happier. Go there. Enjoy it.

Comments

[Nbot2k]

So you've erected a straw man argument, torn it down, and replaced it with nothing. What exactly are you advocating?

[Grant (PG) Rule]

Quite agree. Well, mostly. Releases are just a symptom. The underlying problem is the over reliance on the project concept. Software development has become a one-trick pony.

Other symptoms are the terrible loss of know-how that occurs when teams are disbanded. And the waste that occurs in the 'fix-on-fail' approach to design & development typically evinced by most software teams, whether 'agile' or 'traditional'. The list of issues goes on.

One alternative is flow production. That's been proven to work in all sorts of situations.

Best regards,
Grant (PG) Rule

[David B. Black]

Thanks for your good comment. Of course, "releases" are just a symptom, one that has been bugging me recently in some of the companies I work with. Somewhat more central is whether the software process is optimized for predictability (the usual case) or speed (not so usual), as described in this prior post: http://www.blackliszt.com/2010/10/software-project-management-dates-are-evil.html.

[bluefootedpig]

Clients demand to know when, and clients are not happy with "when we get to it". There seems to be a lack of trust when working with other companies. But we can see by the response that while pushing back a deadline, the people will complain but accept it. People looking for blizzard software have come to not only expect delays, but accept them as part of designing such a solid game.

This actually reminds me of my professor in college who said that software engineering is closer to an art than a science. We can do touch ups, maybe scrap it and start from the beginning, but management sees it as a process that can be estimated. As David pointed out, the process favors predictability more often, but how predictable can software be? even more so when designing new innovative ways to do something?

This is why I like the agile / continual integration model. Writing slices and doing it in a manner that allows for you to update without impacting the system. Requires a very robust system, but extending that system becomes very easy. Just hard to explain to management that 80% of the time will be designing the framework.