undefined | Better HN

0 pointsandrewvc9y ago0 comments

A major point of the agile manifesto was that building any software to a waterfall spec results in unhappy users. Even enterprise software is iteratively designed these days (well at good places at least). Games are not special.

0 comments

hacker_99y ago

Agile is no magic bullet. Additionally 'change' means a very different thing when you are talking about in-flexible data (3d models, textures, animation etc), and usually means throwing the data away completely and starting over. This is a lot more work that adding a form field to a web page, or changing the business logic behind a query by moving some code around.

bartread9y ago

This^^^. Scheduling for some types of software is harder than others. I mean it's always a pain in the neck, but not necessarily intractable.

I used to work on shrinkwrapped tools for SQL Server and .NET developers, and over time got pretty good at scheduling releases with an ever narrowing window (that was never that wide to begin with), even accounting for the inevitable changes you'd need to make as you got customers to try out the software throughout the project. And you needed some degree of certainty over scheduling in order to coordinate with marketing, make sure sales and product support were trained, dovetail with other projects so that people could be reassigned, etc. Key point, as well: teams are cross-functional, but relatively small.

Line of business apps are trickier because you're often dealing with stakeholders who either aren't sure, or can't well express, what they need. You also have the kind of integration problems that occur much less often than with shrinkwrapped software. Cynically, I feel like a lot of unwillingness to schedule for these kinds of projects - especially for moderate team size/complexity - is really because people just don't like doing it, for a variety of reasons. And by schedule, I mean sit down and do the homework as it were in detail, not just throw a convenient date up on the board (I've never seen anyone do a good job of estimating a software project in the large this way, and it doesn't help the business make informed decisions when you end up shifting the date or cutting functionality under duress later on).

You get similar problems with public facing web apps: because you can roll out a new version of the software whenever you want this allows you to chop and change functionality as needed (or wanted), so things can grow tentacles. Team size and complexity can vary a lot here but, obviously, bigger, more complex teams make it harder to schedule. If you're rolling out functionality incrementally though, this may not present a big issue commercially.

Games are a whole other thing, because the feel of playing, and the fun factor are absolutely key. This is also why I don't think film development is a great analogue for game development. Film is not interactive, but games are, which adds a layer of complexity film doesn't need to worry about. And this comes whilst having a production team of a comparable size and complexity to that of a film for big budget games.

To be honest though, I'm not sure how much team size and complexity factors in with games - just watch the Indiegame film where you have very small teams in all cases, yet (particularly memorable with Fez) development takes massively longer than expected, and involves a rewrite to get the game right. If that hadn't happened it wouldn't have been as good a game.

Like I say, I think games really are a different kind of problem - perhaps the closest thing software project management has to an NP-hard problem. It's really no surprise they ship late, and that crunch is a reality. Perma-crunch though: well, that just makes me feel sick to think about.

nradov9y ago

The point of agile is for a team to achieve the maximum possible sustainable velocity. If you're building a custom line-of-business application, a web SaaS, or shrink-wrapped productivity software then you typically want to manage it as an ongoing program with multiple releases spread over many years. So a rational manager won't burn the team out on the current release because she needs to keep the team intact to work on the next release. Whereas with most games there's very little maintenance and enhancement work after the initial release, so it might be economically rational to overwork the team in the short term even if that pace is unsustainable.