« HDD Capacity Improves While Slowing Down. Help! | Main | Bad Customer Service: Whose Fault is 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.

The comments to this entry are closed.