15 ms·
> Finishing projects should not require this and anyone who tells you different is your enemy. I mean that. Enemy? How melodramatic. Finishing complex multi-y
by psykotic 15y ago
> Finishing projects should not require this and anyone who tells you different is your enemy. I mean that.
Enemy? How melodramatic.
Finishing complex multi-year retail projects is never easy. Someone will have to fix those nasty, hard to reproduce crash bugs, find ways to free up another few megs of memory, smooth out those frame rate spikes, etc. It doesn't matter how many politically correct agile practices you follow; you will always be left with critical last minute tasks that are anything but fun and relaxing to complete. You can choose to work on the kinds of projects where this doesn't crop up as much, but games with blockbuster aspirations were never that kind of project.
- by 15y agoMy theory is that un-released software is like physical inventory. Keeping inventory is very expensive because the money spent could have been earning interest elsewhere and product sitting in the warehouse becomes gradually obsolete. As you accumulate a great deal of software inventory towards the end of a big project the cost of keeping the inventory, and therefore the pressure to complete the project, naturally increases. Shipping small increments frequently and not keeping much software inventory is the most efficient process if the product design/market allows. (I'm not saying this is always possible or would have been appropriate in this case, just making a comparison.)