Forgot your password?
typodupeerror

Using Agile Methodologies To Make Games? 236

Posted by ScuttleMonkey
from the faster-and-cheaper-usually-answer-that-question dept.
simoniker writes "Using Agile methodologies for programming is a concept that's been around for a while now, but some firms are now applying the concept to video game development." There has been a lot of talk lately about what the 'next big thing' in development will be. Could this be it? Or is this just another step along the way? From the article: "Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives."
This discussion has been archived. No new comments can be posted.

Using Agile Methodologies To Make Games?

Comments Filter:
  • by eldavojohn (898314) * <eldavojohn.gmail@com> on Wednesday June 28, 2006 @12:45PM (#15622013) Journal
    When I was in college, I was 'taught' how to develop software.

    And so started a cycle of hatred towards methodologies about how to be productive in application development.

    To me, the wild wild web is still here. I still get my kicks from coding without set in stone documentation and I still hate schedules.

    I've always had the view that every project was a wild animal. Worse yet, it's a wild animal in sheep's clothing. And you approach the sheep with a shepherd's hook. When the veil is lifted and you see man eating marsupial with alligator teeth and a scorpion's tail, you have no choice but to throw the shepherd's hook at them and give it all you've got.

    And this is how I approach managing a development project. You remember prior projects and throw together a bag of tools that have worked before and then you set to taming the beast. If you tell yourself "Waterfall works every time" then you're just going to find yourself with a shepherd's hook facing a lion or a bear.

    Instead, you learn to adapt to every situation and that's the important thing. The rules are few and loose. The customer has the power to destroy everything and you have to deal with it. The best development is done on the fly with just enough documentation to convey the big idea of what's going on and keep everyone on that page. Given real life schedules and timed deadlines, there is such a thing as too much documentation.

    Agile development is better in that it allows you more play and doesn't inhibit spur of the moment innovation. I think some of my most demoralizing moments have been when I realized some great new possibility for a project only to have my manager tell me that so much documentation would have to change that "maybe we'll put that in next year's scope." I find this to be ridiculous.

    What was happening was people were starting to assume that waterfall was the silver bullet for project management. "What kind of project is it?" "I don't care, we're using the waterfall." And the big problem is that the waterfall is only considered 'adaptable' if you're ok with reworking everything from step one. Is this really necessary for every project though?

    Another new thing we have these days is a "framework" that fits a specific type of problem well. You can throw these together on the fly and have very little documentation because the framework provides a well known implementation strategy (see Spring's MVC).

    It is my opinion that using an incremental deliverable approach with frequent customer meetings and executive power at any point in the project is the most successful strategy. The "rules" you have to adhere to are up to you and should be purely a case by case basis.

    There has been a lot of talk lately about what the 'next big thing' in development will be.
    Why do we constantly look for the "next big thing" when the "big thing" is simply experience?
    • by mkw87 (860289) on Wednesday June 28, 2006 @12:58PM (#15622110)
      when the "big thing" is simply experience

      Tell that to my fiance!

    • by Anonymous Brave Guy (457657) on Wednesday June 28, 2006 @01:03PM (#15622156)

      I, too, was taught about software engineering processes during my CompSci days. But in my case, the waterfall model was the textbook example of how not to do things...

      Of course, you can take things too far that other way as well. Being too rough and ready -- something encouraged by an "agile" approach -- may get you best results locally, but what matters is getting optimal results globally across the lifetime of the project and all its features. Just as the old hands look at managers trying in vain to match reality to a waterfall model and smile, so they look at young enthusiasts diving in with little to no big picture planning and wait for things to fall apart.

    • by cp.tar (871488) <cp.tar.bz2@gmail.com> on Wednesday June 28, 2006 @01:03PM (#15622164) Journal
      Why do we constantly look for the "next big thing" when the "big thing" is simply experience?

      Because managers don't trust engineers.

      They don't understand what's going on, and yet they have to manage it.
      So they hear about a new methodology, drink it up like a common sucker drinks up Scientology, and turn it into a religion.

      Everything you don't understand you fear, and then you turn it into a religion.
      All too common behaviour, all throughout our history.

      If they tried to understand it all instad, they probably wouldn't be managers; they'd be engineers.

      Most people don't care about how things work; they only want them to work and to work always.

      Magic-minded lot, all of them.

      • Managers <sigh> (Score:5, Insightful)

        by Anonymous Brave Guy (457657) on Wednesday June 28, 2006 @01:11PM (#15622241)

        This is just an issue with management, though. A good manager will trust his engineers (or fire them and replace them with trustworthy alternatives). The manager's job is to set the direction of the project, get the engineers what they need to steer in that direction, and then get out of the way as much as possible and as quickly as possible.

        It's staggering how many managers don't realise this, and hamstring their dev teams with their personal, half-baked, technically-incompetent ideas and/or with excessive procedures and beaucratic reporting because the manager "has to know what's going on". Of course he does, up to a point, but what exactly is he going to do if a developer does tell him that a bug fix was delayed by a day because {$TECHNOBABBLE}? If he's not going to act on some information, he doesn't need to know it, and requiring developers to take time out of their day to "keep the manager in the loop" more than necessary just disrupts development.

        • Re:Managers (Score:5, Interesting)

          by SatanicPuppy (611928) * <Satanicpuppy@[ ]il.com ['gma' in gap]> on Wednesday June 28, 2006 @02:05PM (#15622722) Journal
          I know it's tired old hat, and probably flameworthy in this environment, but a real manager doesn't need to know what the hell you're talking about to make a good descision. All he has to do is know his people, and be willing to listen to their experience. By the same token, the most knowledgable manager in the world can still screw everything up by trying to make everyone do it the exact way he would do it if he was doing it all himself.

          You need to find someone who can keep the final goal in sight, and who is flexible enough to reorganize whenever the requirements change. Agile, Waterfall, Iterative, whatever, it doesn't matter...These are ideas put together so that mediocre managers will have some kind of method that may bring decent results. They can all work great, and they can all work poorly, and it all depends on who is doing the oversight.

          Management actually is a pretty solid skill if you can do it. Too much of the flaming comes from people who've never had the good fortune to work with a good manager. I myself have never worked with one who was the total package...Either they understood the work and the clients and they couldn't deal with the higher ups, or they dealt well with the higher ups but didn't understand the work or the clients.
        • This is just an issue with management, though. A good manager will trust his engineers (or fire them and replace them with trustworthy alternatives). The manager's job is to set the direction of the project, get the engineers what they need to steer in that direction, and then get out of the way as much as possible and as quickly as possible.

          You're missing two vital parts of project management: ensuring the train stays on track, and ensuring that the investors (stockholders, direct investors, whoever suppli

          • Re:Managers (Score:3, Insightful)

            You're missing two vital parts of project management: ensuring the train stays on track,

            Which can never be done reliably for non-trivial projects with the tools and techniques we have available today, regardless of what anyone trying to sell you their book says. No-one has yet shown how to beat picking two of cheap, fast and good.

            and ensuring that the investors (stockholders, direct investors, whoever supplied the $$) is kept aware of progress.

            Which is a much higher level than the sort of day-

            • I think you're missing my point re: metrics. It's not the individual metrics that count -- it's the aggregate metrics that matter in the long term, especially to the highest levels. Without collecting those metrics at the lowest levels, it's impossible to have accurate analysis.

              What if the question is, "Which manager is more effective at making sure their team meets deadline?" or "Which team is hobbled most by inadequate managers, and is therefore a priority for assigning a talented manager?" As multip
        • It's staggering how many managers don't realise this, and hamstring their dev teams with their personal, half-baked, technically-incompetent ideas and/or with excessive procedures and beaucratic reporting because the manager "has to know what's going on". Of course he does, up to a point, but what exactly is he going to do if a developer does tell him that a bug fix was delayed by a day because {$TECHNOBABBLE}?

          The most important thing is never having knowledge, but knowing when your knowledge ends. This is
      • by Anonymous Coward

        You're right. And there's another reason, because many engineers have tunnel vision and cannot grasp that each project has dimensions involving a) the customer, b) money, c) limited time, d) getting it done now instead of wanking around building the Worlds Most Beautiful Piece of Software.

        Every system is broken. Some systems are less broken than others. A new system always has a promise of the better, until we've used it and know for sure.

        • You can have it done cheap, fast or well.

          Managers mostly want cheap and fast. Engineers want well.
          And generally, you can only have one of the three.

          • They're not mutually exclusive. Instead, think of them as the corners of a triangle. You call them "cheap," "fast," and "well" (because it makes better sense gramatically) but call them "cost," "speed," and "quality" respectively.

            The general, and arguable, assumption is that customers are tied to cost, managers are tied to speed, and developers to quality. Usually the trouble comes from the priorty of each group. Customers tend to lean towards cost, speed, and quality. Managers tend towards speed, quality,

      • Because managers don't trust engineers.

        To give a counterpoint, our management is doing Scrum because us engineers asked them to.
    • by Jerf (17166) on Wednesday June 28, 2006 @02:09PM (#15622756) Journal
      Why do we constantly look for the "next big thing" when the "big thing" is simply experience?

      To know how important experience is, one of two things needs to be true: You either need to have it, or you need to be someone who is still interested in "wisdom" in this knowledge-centric era, and be willing to listen to those who have experience, and pick the correct people who say experience is important and believe them*.

      Both are fairly rare.

      The rest follows from "rarity" in the obvious manner.

      (*: I believe wisdom is underrated nowadays, but I won't pretend that the problem of figuring out who to listen to is not itself hard.)

      The other thing is that there are next big things, but I suspect we are slowly but surely running out of "next big things" that will be comprehensible to more than, say, 25% of practicing programmers. Switch to Ruby, learn how to really use it, and add a good automated testing philosophy in, and you've gone a long ways towards extracting all the additional productivity you can get out of your environment without a major upheaval. For instance, I think it's reasonably likely (although not certain) that functional programming is finally going to come out as a reasonable paradigm over the next 10 years as it will be best able to take advantage of multi-core systems without completely upheaving how you write programs, but we're going to lose a lot of programmers on that transition, because it just doesn't click for some people. And that's a major change.
    • To me, the wild wild web is still here. I still get my kicks from coding without set in stone documentation and I still hate schedules.

      And that's essentially what Agile development is: a way of getting things done quickly without overscheduling.

      Another new thing we have these days is a "framework" that fits a specific type of problem well. You can throw these together on the fly and have very little documentation because the framework provides a well known implementation strategy (see Spring's MVC).

      If by "n
    • Why do we constantly look for the "next big thing" when the "big thing" is simply experience?

      Because experience without intelligence, taste and good good judgement is practiacally useless.

      Experience converts a bright young developer into a very good older developer. It converts a stupid young developer into a stupid older developer with a big ego and a bunch of fixed ideas about what's possible and what's not possible based on the irrefutable evidence of their experience.

      I've had the misfortune to work on
    • I've always had the view that every project was a wild animal. Worse yet, it's a wild animal in sheep's clothing. And you approach the sheep with a shepherd's hook. When the veil is lifted and you see man eating marsupial with alligator teeth and a scorpion's tail, you have no choice but to throw the shepherd's hook at them and give it all you've got.

      I agree. You can code much better on LSD.

  • Most aggravating (Score:4, Insightful)

    by neonprimetime (528653) on Wednesday June 28, 2006 @12:50PM (#15622049) Homepage
    because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.

    I like this ... cause that last pair of words ... wasted work ... seems to hit my teams especially hard quite often right now. We'll finish LARGE tasks, perhaps bundle multiple items together into one large release (cause this is how management wants it) ... and by the time it gets to UAT testing many development hours have been spent ... and then the UAT tester will turn around and say ... nope ... don't need/want that ... and thus all those development hours are wasted. I'd love to get a workflow like SCRUM implemented in my workplace.
    • Re:Most aggravating (Score:2, Informative)

      by Anonymous Coward
      The studio I'm in uses this process and it really helps keep all the teams on the same page.

      Our team meets every morning at 11:00am and we discuss our progress and share any issues that come up. Interopability problems come to light very quickly and are dealt with in a few hours / days instead of months down the road.

      One thing that we say in our SCRUM meetings is, no sitting! Keeps it short, sweet, to the point and people are alert through-out the meeting.

      We try to break up all our tasks in to two day work
    • And then when you finally do, you will complain because users can't get anything in the project anymore.

      I had to work with project management before using scrums. The management describes the scrums, the developers do it and then the user complains because the user doesn't want what management decided. And then the developers can't satisfy the users since management decides what goes in the scrums and the users don't have any influence anymore. This leads to bloated apps full of features that nobody uses an
  • by Anonymous Brave Guy (457657) on Wednesday June 28, 2006 @12:51PM (#15622051)

    There has been a lot of talk lately about what the 'next big thing' in development will be. Could this be it?

    I doubt it. Smart dev teams have been using iterative development cycles and keeping their code tidy since a long time before anyone coined the buzzphrase "agile" (or using SillyCapitalLetters and calling things "extreme", or any of the other hype we've put up with lately).

    • Yeah. A bunch of Harvard MBA idiots realized their methods sucked, so they watched how good programmers do it, then slapped a label on it, published a book and mandated it.

  • My current project is using Agile methodology for development. It's great when you don't have full requirements at the beginning of the project. It would be interesting to apply this to games, and really makes sense. It seems like this would be much more organic approach and I could see it really useful in large games such as WoW where you can develop different areas while in production. A successful choice of methodology really depends on your project and what would be best for the team. Your choice o
  • Buzzwords aplenty (Score:4, Insightful)

    by lawpoop (604919) on Wednesday June 28, 2006 @12:53PM (#15622076) Homepage Journal
    "creating prioritized vertical slices that iterate on the most critical elements and features"

    Can someone tell me what this means?
    • by neonprimetime (528653) on Wednesday June 28, 2006 @12:57PM (#15622101) Homepage
      For example ... in Tomb Raider
      One team should concentrate on Lara's Face, one should concentrate on her chest, and one should concentrate on her Legs. No wait ... that's horizontal slices.
    • It means that when the game is rushed out the door unfinished in order to meet a deadline, at least the portions that are completed will actually work.
      • When I was working at Atari as an lead tester, that was normally the case since the developers had to turn in a milestone that can be played from beginning to end, and, if the game needs to be shipped out in the hurry, the game was usually playable until the end where all the compromises are made.

        Except the developers for DBZ: Buu's Fury (GBA) had a very different idea on deliverable milestones. They provided the first third of the game at Alpha, the second third at Beta, and the final third at Code Rele
    • by rs232 (849320) on Wednesday June 28, 2006 @01:03PM (#15622157)
      "Can someone tell me what this means?"

      Some systems analyst draws some connectors and boxes and you get to sit up till 4:00 am writing the code.
    • by Salzorin (985348) on Wednesday June 28, 2006 @01:08PM (#15622213) Homepage
      I'd like to, but it's really not on my deliverables for this quarter. If we could interface sometime during the next iteration, I feel like we can drill down this action item further and really bring this to manifest. I look forward to addressing your critical concerns and reaching some new plateu in our correspondence.
    • Re:Buzzwords aplenty (Score:3, Informative)

      by rwhansen (644117)
      Some methdologies develop each subsystem fully then integrate them in a big bang at the end. Agile practitioners develop whatever parts of each subsystem are needed to support the features in the current iteration. If you think of the subsystems as layers, the vertical slice is the part of each layer that is being developed in the current iteration. The features should be prioritized in order of importance, so each iteration is working on the next most important feature or features. The idea behind all this
    • Re:Buzzwords aplenty (Score:5, Informative)

      by magicjava (952331) on Wednesday June 28, 2006 @01:20PM (#15622307)
      "creating prioritized vertical slices that iterate on the most critical elements and features"

      Can someone tell me what this means?


      Sure. It means get something simple working as quickly as possible and improving it over and over.

      prioritized - Pick your most important features and implement them first. For example, if you're writing a word processor the ability to save a file probably has a higher proiority than a spell checker.

      vertical - This means "specific" as opposed to "general" (also called horizontal). So you work on specific features (like the saving of a file mentioned above) rather than more general ones (like optimiztion).

      iterate - You're not going to do things all at once. As an example, perhaps your first iteration of saving a file only saves text and no formating information. You're second may add formatting, your third may add additional formats.

    • by glindsey (73730) on Wednesday June 28, 2006 @01:30PM (#15622382)
      "Hack something together that you can show the sales folks, and then keep adding to it with horrible kludges until you get something resembling the final product which complies. Ship immediately."
      • by Kadin2048 (468275) <slashdot.kadinNO@SPAMxoxy.net> on Wednesday June 28, 2006 @03:17PM (#15623269) Homepage Journal
        "Hack something together that you can show the sales folks, and then keep adding to it with horrible kludges until you get something resembling the final product which complies. Ship immediately."
        I know you're being facetious, but that's exactly what I envisioned whenever I hear about these "agile" methodologies.

        I guess it's because I work on software where the tolerance for bugs is a lot less than it is (apparently) in desktop PC software, but I have a hard time seeing one of these methodologies producing clean code.

        If your application is going to get shipped and then never looked at again, I guess "clean code" might not matter, but if you're building an enterprise system, or writing a custom application that has to be maintained by other people later (people who probably aren't going to be quite so much of an 1337 h4x0r as you), it's a must.

        Documentation and specifications aren't just something that you do in order to satisfy the PHBs of the world; they serve a real function. A system that's been well-specified to begin with is much easier to fix later, at least in my experience, than one that's been produced during a death march and is nothing but a giant rat's nest of code.

        I could see the benefit of an "agile" development cycle for prototyping or producing a quick demo, but the idea of critical pieces of software -- software that your customers are going to depend on and that other people, months, years, or decades down the line are going to have to maintain and update -- being built this way scares me a little.

        Listening to programmers bitch about documentation is like listening to a bunch of carpenters bitch about architectural plans. Of course you could get the house built a lot faster if you just took 15 builders and said "hey you, build a wall here!" and "you, build a bathroom over there!" ... but I wouldn't want to live in the resulting house. Would you?
        • Re:Buzzwords aplenty (Score:3, Interesting)

          by Surt (22457)
          We use an agile methodology for our enterprise code (deriving from SCRUM).

          The benefit in terms of reliability and maintainability is that typically multiple engineers are forced to work on any given piece of code before it reaches the maintenance stage. This will tend to force anything that is poorly written to get rewritten along the way.

          Specifications (really tight specifications) are a must for this methodology to work right. I can start building you the 1.0 version as soon as you hand over a really de
    • by sammy baby (14909) on Wednesday June 28, 2006 @01:39PM (#15622465) Journal
      That was a fancy way of saying:

      1. You start with an extremely barebones (read: you'd never release this into the wild) program that actually runs, passes all its unit tests, and implements maybe one important feature. (eg: a shopping cart program which will show you the contents of a catalog.)
      2. With each iteration, you add a new feature, refactoring older code as necessary. Start with critical functionality and work your way down the requirements.
      3. Continue until the product is releaseable.

      The "vertical" bit means that rather than taking the "let's implement all the methods we'll need in the CatalogItem class first" approach (horizontal), you're trying to make it actually do something useful (eg, show a list of products) with each iteration.
    • Re:Buzzwords aplenty (Score:4, Interesting)

      by Jhan (542783) on Wednesday June 28, 2006 @01:55PM (#15622626) Homepage

      At my current gig (OnGame ie. PokerRoom.com) we've been using a kind of modified Scrum. The idea is to start "El Project Grande", spend a day breaking the project into parts and deciding what depends on what, then spend another day in groups breaking down the parts into parts until you have tiny pieces which ideally will take less than 16 man hours a piece.

      You now have a big pile of tasks, sub-tasks, sub-sub-tasks and so forth with dependencies and time estimates (all set by the programmers themselves.) It's then up to the Scrum Master aka. "Get-those-assholes-off-our-back-person" to show the results to the customer and decide priorites.

      The priorities are passed to programming team, and they then plan the first "iteration". Now, the goal of every "iteration", which typically spans max one month, is to produce a fully implemented, tested and launchable subset of the complete product.

      Every day, all the coders have a *short* meeting (10-30 min). Each individual states what he is working on, what he's done since the last meeting, what he's planning to do until the next meeting and most importantly he's strongly encouraged to cry for help if he's blocked in any way.

      In addition to this there's an evil, buggy Excel sheet with all the (sub-sub-sub)tasks along the vertical, and days along the horizontal. It's each programmers responsibility to update estimated hours left for tasks he has been working on each day. NB! *hours left* It's prefectly alright to up the time remaining if you have unexpected problems. So a certain task may go "16 12 4 56" hours left.

      The main points of Scrum (for a programmer):

      • The programmers set all time estimates.
      • Individual programmers may change any estimates upward without hard feelings.
      • (In our version) The programmers hire new programmers.
      • The programmers allocate work among the programmers.
      • In fact, the programmers control their own work 99%.
      • The Scrum Master aka. ('Nearest-thing-we-have-to-a-boss') deflects all flack and handles all communication with harpies^W customers.)
      ...and that's how it's supposed to work in the best of worlds. In reality, however, the whole model crashes and burns if * The projects are to short (
      • Dog man it!! As I was saying, the whole model might work unless:
        • The projects are to short (<3 months)
        • Workload goes way up (who's gonna update the stupid Excel document)
        • The customer finds inside channels and pesters individual developers to "We just need this one thing fast..." ten times a day.
      • Have you tried using Xplanner instead of a spreadsheet? It works very well.
    • "creating prioritized vertical slices that iterate on the most critical elements and features"

      Can someone tell me what this means?


      It is an improved development methodology wherein the older spiral development methodology, which was characterized by repeatedly iterating a set of elemental development processes and managing risk so it is actively being reduced, is enhanced by managing stakeholder life cycle commitments via the LCO, LCA, and IOC Anchor Point Milestones with the degree of detail of artifacts pr
  • by Anonymous Coward
    Any time you see someone interviewed about game development on the web or in a magazine chances are pretty good that the reason that person has the time to waste is they aren't valuable enough to be busy doing actual work on game development.

    You see them in the lunch room, outside with the smokers, hanging around in the halls of the building. Always talking about stuff with lots of buzz words, like say 'agile' for example, all sorts of very advanced sounding tech almost all of which they know very little ab
    • LOL. I'm laughing because usually I'd agree :-) But why? Well, because most games studios I've worked involved near constant death-marches to ship product. I'm now a Senior Architect at High Moon (where Rory works) and I'm amazed to say that (a) I have spare time and (b) our productivity is much higher than any other place I've worked. Now I admit that being a total geek I end up working late a lot anyway, but its on interesting avenues and experiments rather than fixing the bugs that I introduced when I wa

  • by cculianu (183926) on Wednesday June 28, 2006 @12:55PM (#15622087) Homepage
    Agile development with C++? Sure, it can be done. But one of the nice features of that language is its ability to model the application domain using Classes, Objects, Inheritance. If you don't take the time to model the problem correctly, you can painfully pay for it later on. Sometimes you get faster development times if you actually take a day or a week and model your problem so that it captures the essense of what you are trying to solve using objects, etc.

    An iterative approach where you use a greedy method of implementing each new feature as quickly as possible with little insight into the overall system may or may not produce optimal results. It can lead to lots of spaghetti code. Or maybe not. Certainly in my career that approach sometimes *has* led to cleverer solutions as I was forced to think up the best, simplest way to imlement them. But often it can lead to massive amounts of spaghetti code that doesn't make much sense or capture any insights into the problem.
    • An iterative approach where you use a greedy method of implementing each new feature as quickly as possible with little insight into the overall system may or may not produce optimal results.

      You need to refactor the system when you add the features so that the system stays in balance with the new feature. Otherwise its just a hack.
      • Which leads to a lot of code churn and a system where noone really knows what a given subsystem is doing, unless you were the last one to touch it.
        • by Jerf (17166) on Wednesday June 28, 2006 @02:13PM (#15622789) Journal
          Which leads to a lot of code churn and a system where noone really knows what a given subsystem is doing, unless you were the last one to touch it.

          Two counterpoints:
          • This is different than normal coding practice how?
          • It's all about costs and benefits. Sure, there are the downsides you mention, but on the other hand, aggressive refactoring means you don't necessarily live with your first design forever and ever, amen, as (go figure!) your first design also happens to be your worst. So, is it worth it? Depends on your situation. But in my experience, between "code churn" and "first generation design enshrined in concrete forever", the former is very preferable on all but the shortest time scales. YMMV.
          • THe better answer is planned refactoring. Don't undergo major code churn by refactoring willy nilly. Figure out what about the current architecture is sub-optimal. Discuss with your team ways to architect it better. Then implement them. But rapid refactoring just leads to badly designed, hard to maintain code.

            The exception here is on very small teams- 1 or 2 people. Then code churn isn't an issue because 1 person is doing all the churning. But thats not the normal case.
            • There's a such thing as "unplanned refactoring"?

              No programming methodology I know of says "just shut your eyes and follow this recipe and you can stop planning and thinking entirely!" Now, plenty of people's misconceptions about methodologies incorporate that, but I've never seen anybody actually say that.

              XP, probably the one the most people think this of, really just says to pull your planning window in much closer to the immediate future than most methodologies do; nowhere does it say to not think at all,
              • Sure there is- unplanned refactoring is refactoring for what you need right now, as espoused by most agile methodologies.

                Planned refactoring is a thought out and designed out refactoring, taking into account current and future use cases. You take a list of problems with your current architecture, take a day or so, and figure out the best way to do it. Get input from teammates who need to live with your choices. As opposed to the agile method which frequently turns into "whats the quickest way I can hack
    • It only sounds like that if you skip the important parts.

      Agile methods are not about skipping requirements, or modeling, nor about coding in a casual or non-deliberate way.

      Agile methods are about recognizing that requirements are a moving target, That the more you implement your solution, the better you will understand the model, and possible problems with your model of the problem domain, and that the best program on earth is worthless if it doesn't work for the end users.

      So, there's a large collect

  • by darrenf (746898) on Wednesday June 28, 2006 @12:56PM (#15622095) Homepage
    creating prioritized vertical slices that iterate on the most critical elements and features


    But can I synergize with my results-driven knowledge base while partnering with self-managed teams, increasing single-source responsibility while undergoing a complete paradigm shift?

    I didn't think so.
    • But can I synergize with my results-driven knowledge base while partnering with self-managed teams, increasing single-source responsibility while undergoing a complete paradigm shift?

      I didn't think so

      No wonder you can't, nobody can do all of those three positions from the "Kama Sutra of Software Development" at once - "Synergizing with a results-driven knowledge base" by itself already requires an unusual ammount of body flexibility ... not to mention being really really carefull.

  • by Anonymous Coward on Wednesday June 28, 2006 @12:59PM (#15622120)
    Working at a major game company, here's what happened when someone here raised XP:

    The guy who suggested it, "It's an itterative development model. We identify core features, develop those features, refine those features with the customer, then add the next layer, repeating as we go. We gain much better code as every component meets the customer's need as it is developed, challenging the customer to think about it in context, and allowing us to add additional itterations if needed."

    Management, "So, we can identify additional features throughout development?"

    "Absolutely. You just have to assign additional resources (time/people) to account for those extra features. But, by identifying them as they come up, you end up with a much better system that really does everything right."

    Over the next few months, features kept getting added, developers dutifully updated schedules. All was happy. Followed by...

    Management, "This was supposed to ship before thanksgiving. It's now slated to ship in the new year. We'll entirely miss the holiday season."

    Rapidly realizing his mistake for suggesting it guy, "Yes. But you kept coming up with new features. And they are great new features. Think how much better the product is for it."

    "If we miss the holiday season market, we lose money. This has to ship 'on time'."

    "But on time is a function of how much you add. We're developing everything to schedule. You've just increased the features so increased the schedule."

    "The schedule can't move."

    "So you'll have to lose some of the remaining itteration milestones. You'll have to drop features."

    "But we like all the features we've come up with."

    "But adding features adds time. You've known that since the beginning."

    "We've known this has to ship for the holiday season and you promised us we could have extra features. You're just going to have to work more overtime. Fortunately you're overtime exempt so that won't cost us anything to get this project back on schedule."

    "It is on schedule. You just changed the schedule by adding features that were identified along the way."

    "You told us your wonderful "XP" model would let us do that. We gave you the chance to try this new method under the understanding we got these benefits."

    "And you do."

    "Good. Then make your schedule."

    "We are mak-"

    "No arguments. This discussion is over. You promised you could deliver the extra features. You're now behind schedule for the holiday season. You're just going to have to crunch. End of discussion."

    Yeah, thanks XP.

    Never, ever, raise exciting new methodologies to management. They will hear all of the advantages and expect every last one of them as though it was the perfect implementation of the method whilst completely failing to hear (and certainly refusing to act on or implement if they do hear) any of the trade-offs that have to be made to enable those gains.
    • That's not a problem with XP. That's a problem with your PHB.
    • by hhr (909621) on Wednesday June 28, 2006 @01:30PM (#15622388)
      The developers also made a mistake in not realzing where their paychecks come from-- selling finished games.

      If someone is paying you to write software then "Earning out paychecks" or "keeping on budget" must be a critical feature. We may like to think otherwise, but companies don't pay you because they love you. They pay you because you earn more money for them then you cost. If it was the other way around, your paycheck would bounce and/or layoffs would ensue.

      • by Anonymous Coward
        Wrong. The developers should not worry about selling finished games, that management's responsiblity. I agree that 'keeping on budget' is a critical feature. But with agile methodologies, that is management's concern. Assuming that the developers were working at an acceptable pace, who made the decision to push back the release date?
    • Your story there further proves... no matter WHAT the methodology is called, the old adage remains: "Quality, Cost, Schedule: Choose Two." Except in software, the other two can't always be fixed by spending more.
    • Your problem is not XP, your problem is lack of management buy-in. No matter how you develop software, if your management does not support it, you have a problem.
  • Mumbo Jumbo (Score:3, Funny)

    by Anonymous Coward on Wednesday June 28, 2006 @01:01PM (#15622134)
    Sounds like more touchy feely mumbo jumbo to me. Coffee, red eyes, bad breath, late nights, divorce... that's how software gets done dammit..
    • While reading the list, I was about to recommend some over-the-counter drug like Nyquil, but when I reached divorce, I was at a loss. Nyquil can aid many things, but probably not divorce. =)

      (or "wife aggro" as I've recently learned it)
  • Agile methods suck (Score:2, Interesting)

    by Anonymous Coward
    We're using them where I work. They cause a huge mess in communication and a lot of grief for the developers. It also allows the designers to change their minds on a whim - which means that the project keeps stalling.

    SCRUM doesn't keep a history, so you have no way of checking to see if your estimates are historically too high, too low, or all of the above, and so there's no way to see if you're going to hit things on time.

    There is no magic bullet. And when you've got a lot of people who need to keep workin
  • by bunions (970377) on Wednesday June 28, 2006 @01:04PM (#15622175)
    as everyone else pointed out, it's mostly just a name for what people have been doing for a while when upper management leaves them alone.

    That said, I've found the hardest part of the process to be finding a client who is willing to put up with the constant back-&-forth and interminable beta testing. Customers generally just want to tell you what they want, go away and then have you magically deduce what they actually need, and can be irritable when you tell them you really can't do that because ... you know ... agile!

  • by Mysticalfruit (533341) on Wednesday June 28, 2006 @01:06PM (#15622188) Journal
    Tragically, I couldn't RTFA because of th excessive market speak.

    In order to energize the evolution of computer games we need to synergize on the vertical slies... WTF?

    I guess people forgot to mention that writing computer games rates up there with writing operating systems in complexity...
  • by MagikSlinger (259969) on Wednesday June 28, 2006 @01:07PM (#15622201) Homepage Journal
    When I was in the game industry, this was how we always did it, even EA does it to an extent. Why? Because the publishers want results. Usually every month or you won't get paid. So as a result we had incremental releases with more and more features added in, and as a bonus, sometimes working. X-D

    P.S. With few exceptions, most game teams do NOT have specs or docs. If they're lucky, they have concept art and some clue what the game is supposed to be. I remember having to code up front-end screens and the artist & I had to figure out what they were supposed to do because the game designer was still writing the specs for the screen we finished last week.
  • 30 day sprints? (Score:3, Insightful)

    by magicjava (952331) on Wednesday June 28, 2006 @01:10PM (#15622235)
    30 days is fast? I wish I had 30 whole days to do my projects!

    I love iterative development, but scrum didn't impress me much when I was involved with it. Perhaps that was just due to the management that implemented it. We went from logging bugs and tasks in bugzilla to writing them on index cards (do I really need to point out to computer people how stupid that is?), and trying to plan projects on these obscure, poorly implemented planning tools.

    Iterative development is great, but scrum strikes me as nothing more than another useless management fad.
  • by th1ckasabr1ck (752151) on Wednesday June 28, 2006 @01:11PM (#15622242)
    I program games and I've thought about this a lot. I kind of like the agile approach, and I think that a lot of the concepts could be useful. One of the major components of being "agile" is building unit tests and relying (at least somewhat) on those as a way to make sure that these rapid checkins are not breaking semi-related systems.

    With games it is UNBELIEVABLY difficult to write unit tests that effectively catch problems. With animation, physics, AI, the built in randomness with the game, the human interaction, etc. it's unbelievably difficult to write unit tests that can get the job done.

    It's easy to write a unit test that says, "When I shoot a dude with this gun, make sure his health goes down by 50". But it's an entirely different thing to say something like, "Make sure that when a battle is going on nobody gets caught up on geometry and can't path to their movement goal."

    Sure it's possible to write small little unit tests that make sure a dude can get from point A to point B, and that this guy knows how to path around a dynamic object if a crate falls in his way, but this isn't something you can effectively break up into little parts. I've fixed too many bugs that are a strange and unfortunate combination of all the aforementioned systems to fall into the trap of thinking isolated unit tests are going to get the job done.

    I am a big fan of the idea in theory, but I can't imagine it being implemented effectively in practice. I would love for somebody to prove me wrong!

    • Still, imagine if you did go to the effort to create tests (not necessarily "unit tests" but "integration") for your game. Imagine the test procedure in pieces as follows:

      Set-up:

      1. Load level geometry (perhaps as a simplication point, create a test level)
      2. Place dummy players and computer players in the level; dummy players do not move
      3. Run for 100 game "ticks"

      Verification:
      1. Check if computer players reach dummy player location
      2. Check player lost life

      It would be desirable if the tests ran quickly
    • Solve specific bugs (Score:4, Interesting)

      by Prien715 (251944) <agnosticpope@@@gmail...com> on Wednesday June 28, 2006 @05:57PM (#15624358) Journal
      We're in the process of implementing further unit tests under the agile model (though not gaming related, it is a heavily interactive app). The idea behind unit testing is to:

      1) find bug
      2) write unit test for bug.
      3) write fix.
      4) verify unit test/program both work. If unit test works, but program fails, go to step 2.

      1) In your example, a tester/coder would find see some soldier dude getting stuck in the middle of battle.
      2) So do it again, saving the game before the bug occurs. Write a unit test which loads this save and then check after x seconds to see where the soldier is and then fail the unit test cause he's stuck behind the crate. The unit test will is not in any way general. It's not meant to test all your pathfinding issues, just this one.
      3) Rework the pathfinding code.
      4) After you notice the unit test passes, go in and see if the bug is still physically in the game. If it's not, you've fixed it. If it still is, well, write another test. You may end up with a dozen pathfinding unit tests this way all of which "fix" some sort of bug.

      The idea behind this methodology is that let's say your new pathfinding algo causes a bug which developer B fixes, but which causes the original case to break. Your unit test will now "clue you in" before a checkin occurs. It also free testing to do more "battle" and "feel" stuff.
  • by mrkitty (584915) on Wednesday June 28, 2006 @01:13PM (#15622252) Homepage
    What do you think I'm lying? :)
  • pushing envelopes (Score:4, Interesting)

    by drDugan (219551) on Wednesday June 28, 2006 @01:23PM (#15622324) Homepage
    games have pushed the envolope more than any other area in computer software development

    the current rising tsunami happening right now with agile development for web applications (like Ruby on Rails, and similar approaches happening in Perl, Python, java and others)... will take games by storm, in my opinion. there are a few factors here that will make games really interesting:

    there will be much more scripting in games,

    there will be much more meta-programming (code writing code)

    there willo be more layering and customization in the languages we use - with more powerful and expressive languages deep underneith, but with tightly constrained, layered (or mixed-in) frameworks that enforce best practices built on top. we have seen this progression going forward for the last 10 years or so, and it's starting to get really interesting now.

    and on the next 5-10 year horizon, we will see applications (driving mostly by desire for better AI in games) that are human-competative in reasoning and interaction - I offer this conjecture without proof, but with significant anecdotal evidence to support the assertion.

    I watching for signs of two important things in computer development: a code base that can write another codebase (metaprogram) that is (1) aware of what it just did and (2) can communicate in a complex novel way with the new code set (I'm being vague here, but you get the idea -- think compiler theory for AI), and ... a fully autonomous systems that can operate a *power plant*. Once those two things happen, humans are toast. I'd estimate that to be about 2060.

  • by LaughingCoder (914424) on Wednesday June 28, 2006 @01:25PM (#15622343)
    I have been developing products for a long time (decades if you must know). For what it's worth, it is my experience that the people on the team have by far the biggest impact on product quality, timeliness, and all those other goodness measures. I believe that the methodology is almost immaterial. Good engineers will instinctively use the appropriate process for the problem at hand. Now, this doesn't necessarily scale to very large projects, which is why I am a firm believer in loose coupling. As soon as practical, decompose the big project in to a collection of loosely coupled smaller projects and then put in place the teams (unfettered by process dogma) to develop the pieces. Ahh, you ask, but what process do you use to decompose the system? See my earlier comment - choose a small team of very good engineers and have them do it. Don't tell them how -- they already know that. Trust people, not process. Ironically there is one process that I believe is critical to every organization's success, and it probably the least-studied, least-optimized, least-formalized process every company has ... and that process is the interview process. Clearly if I am going to trust my people to do the right things and make the right choices, I had better hire the right people. Anyhow, that's about $0.93 more than my $0.02 so I'll step down off my soapbox now.
    • I believe that the methodology is almost immaterial. ... which is why I am a firm believer in loose coupling.

      Hm. Of course, "loose coupling" is a kind of methodology, no? :)

      (I do agree with you though.)
    • Ah, but hiring in itself is a tricky thing (trust me, I study this): it is very highly studied, highly optimizable, and can be made VERY formal.

      Interviews are great--as long as they get at standard information. Otherwise you end up asking applicant a one thing and applicant b another and then you have no clear way to determine which is better. Under this method you end up with 'good enough', rather than 'the best we can find at our budget', which is not really the same thing at all.

      If you want more inform
      • I agree with everything you said. I believe this a process which can and *should* be formalized. My experience is that at most companies this is not the case. And in those companies that do attempt some sort of formalization there is a distressing (in my opinion) trend towards these "personality/behavioral-based' interviews, leaving less time to assess technical competence and "passion for product development".

        FWIW, I was exposed to a very rigorous and (I think effective) interview process at the second c
    • For what it's worth, it is my experience that the people on the team have by far the biggest impact on product quality, timeliness, and all those other goodness measures. I believe that the methodology is almost immaterial.

      This may be true, but the software industry doesn't work that way. Managers want people to be interchangable parts, because that way they can easily replace them when they leave. So they focus on methodology.

      Ironically there is one process that I believe is critical to every organization'
  • by PIPBoy3000 (619296) on Wednesday June 28, 2006 @01:26PM (#15622352)
    But if I were going to name two things that seem to help, they would be:
    • Few, smart people Smaller groups of developers (preferrably one) seem to get so much more done than tons of people working on a project, requiring coordination and creation of standards. I realize this is often mocked, comparing it to the mythic hero developer, locked away and producing great code. Still, in real-life situations I've seen big development groups fail or work at a snail's pace while the single smart person cranks out application after application.
    • Evolutionary prototyping. This is similar to agile programming, basically coming up with something that works and refining it until it's "good enough". I find applications are never firmly done, but rather the fixes and upgrades slow over time. Now if you're building missles or medical equipment, this isn't the best approach, but for most normal business software, I find it works best.
  • by Quiet_Desperation (858215) on Wednesday June 28, 2006 @01:44PM (#15622515)
    "Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives."

    So the game is to figure out what bullshit like this means?

  • by Aceticon (140883) on Wednesday June 28, 2006 @01:47PM (#15622555)
    The problem using any software development methodology which requires user feedback for new product development is that you don't actually have any users - best you can get is a marketoid and those change their minds every 5 minutes.

    You see, the closest you have for a user of a new game is a gamer and those can't really help you refine your requirements 'cause all they want from a game is to be entertained and they don't really know beforehand how a new, entertaining, game will look like - "having fun" is hardly an easy to define business process.

    Maybe some sort of mixed approach where you have a game designer with an overall view of the game concept and a generic pool of gamers to check out the "fun factor" during game development. Might work well for games with an "exploration" component (for example RPGs) for which you can design the early levels, "test" them with some gamers and then use the result to fine tune those levels and later ones. Still, i doubt it can be usefull in game genres such as RTS and Sims.

    More in general, and judging from the posts i've been seing in ./ for the last couple of years, the main process problem with game development seems to be that a lot of the control over the final product lies with Marketing, and worse, Marketing is in a different company altogether (the producer) than game development - so even with good managers on the software development side (already unlikelly) it's difficult to control the the flow of wacky ideas "that just have to be included in the game" coming from the marketoids - thus requirements creep is rife, which almost guarantees that long hours and death marches are standard.
  • by brouski (827510)
    Thank goodness!

    Now I can finally use that +20 agility enchant!

  • This has been the method utilized by many Indie game develops for years, if not decades. I'd hardly call it "the next big thing," since it's been around for quite a while. Perhaps big developers haven't been using this method, but it's been around for longer than this article thinks.
  • The problem right now is that too many companies are developing new technologies, implenting them and then sitting on their propriotary coding so that no one can steal it.

    This is adding a huge amount of redo-work in the industry. Right now, many video games are requiring budgets bigger than blockbuster movies because of this mentality.

    There is not real standardized programs and artwork. Almost all graphics are recreated for every single game out there.

    This is like movie makers getting rid of all backgrou
  • A pipedream (Score:3, Insightful)

    by llZENll (545605) on Wednesday June 28, 2006 @02:36PM (#15622987)
    Seems like the whole idea the article suggests is a pipedream. So their great and new idea is to complete the most important features immediately, then refine them. Well that is all great, but what about the fact that a game usually isn't remotely playable until it is 90% done, no matter which pieces you work on or do in what order.

    This reminds me of something I just read about how episodic content will never work, as making episode 1 requires 95% of the work of the entire game.
  • Show me the money! (Score:3, Insightful)

    by slcdb (317433) on Wednesday June 28, 2006 @02:37PM (#15622992) Homepage
    Show me raw, tangible statistics pitting Agile methodologies against other more traditional approaches, like "waterfall". I'd like to see a whole range of games (or other applications), developed using various methodologies and scored based on parameters like: shipped on time, end product quality, popularity, critical review scores, and, of course, amount of profit. This would be the only way to see how much "better" Agile is compared to other methodologies. Otherwise this is all just theory, speculation, and unadulterated opinion.
  • Sorry, can't read TFA, uuungggh...can't get past the title no matter how much of a running start I get. Why do people keep saying "methodology" when they mean method? Though I've never found a use for the word myself, I suppose that methodology would be the study of methods. What's "agile" got to do with programming? Weasels are agile...so this is methodological advice given by weasels? Oh nooo...can't uncross my eyes--somebody take me to the emergency room!
  • by Weaselmancer (533834) on Wednesday June 28, 2006 @02:47PM (#15623066)

    From the blurb:

    Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production

    So what this does basically is get something that just barely works up for review as quickly as possible. Like throwing a lump of clay on a table and saying, "There's a vase in here, somewhere."

    This IMHO will do two things. First, it will give SW managers a warm feeling caused primarily from too much optimism. "All the engineers have to do is shape that clay a bit, and it's a vase! We're ahead of schedule!" Two, since they will think they're ahead of schedule, they'll report to their superiors about how they already "have a working prototype of a vase" and that'll bump up the schedule.

    The engineers who actually have to implement things will know better. And they're the ones who will get stuck with the deadline. The agile pony show where you show your manager something that boots but doesn't have 98% of the functionality in it will bite you in the rear later on.

    This method doesn't seem well suited to making software. However, it does seem well suited to making managers feel good. I'd avoid it.

  • Since when has people STARTING to adopt methodologies been worthy of slashdot? Game development takes years if this honestly works that's fine, but we need to know of games that were fully created with Agile methodologies.

    There's a few flaws. Can someone tell me why a working prototype would be better when you're working in a company of a couple hundred people? I work at a semi major game developer and let me tell you, working on a early game type, you need those design documents just because you have no
  • by Sarusa (104047) on Wednesday June 28, 2006 @02:50PM (#15623091)
    This is nothing new in game development, even at large companies. 'agile' (with a little A) has been used for at least a decade. You just can't possibly build a good game with the waterfall model and we've known that forever. I think it's a bit like every generation thinking they invented sex.

    We use nightly builds (a single day without a working build is a huge hit). Getting the framework working so your designers and texturers (and gameplay folks) can start trying stuff in-engine, then fleshing out features. Midding sized time periods (2-4 weeks) between major builds. Unit testing. Though we have to bring in humans to really break it when it's all put together.

    Now if you mean Agile with a capital A, then it's not the next big thing, it's just the same bullcrap it was when it was called eXXXtreme Programming. We like to write things down and design a lot of things up front, which clashes with Agile (and don't tell me it doesn't, even with the lip service) - you need at the very least a production bible for large project games to keep everyone together. Parts of the design will sometimes not survive actual implementation and will be tossed, but in general they keep things on track and usually only need some tweaking (everything gets tweaked during playtest time).

    If you don't do this sort of thing you end up with http://en.wikipedia.org/wiki/Dungeon_Lords [wikipedia.org], which is what you get with a Agilely (with a capital A) developed game. It shipped only half complete with no internal cohesion at all and still isn't finished. But the great thing is that you can use your Methodology to justify it all.
  • RUP (Score:3, Insightful)

    by Maxo-Texas (864189) on Wednesday June 28, 2006 @02:52PM (#15623111)
    As a programmer, I like RUP.
    As a project lead, I like RUP.

    It has aspects of Agile to it.

    The important parts are:

    Get the risky stuff addressed early. If DX9 doesn't support bi-pixar multi-shading like it says it does, then it is best to find out early rather than at the end.

    Do the work in measurable chunks. That way you know in as little as a month if you are falling behind schedule.

    Frequently interact with the users to make sure you are on course. This is the biggest problem with waterfall projects- working 6 months on something and it turns out you made a wrong turn on week 2. And I've seen other programmers do this again and again even with user interaction- they get an idea of what the program should be like in their head and turn off input from reality.

    All the documents and crap bother me to and feel like useless makework. At least video game programmers do not have to deal with SOX compliance issues.
  • Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives.

    God knows managers have to find something to talk about to justify their salaries.
  • I'll pass (Score:3, Funny)

    by rabbot (740825) on Wednesday June 28, 2006 @03:35PM (#15623376)
    I'll stick to loading up agility on my Thief for that trick attack multiplier.
  • Structured coding (Score:3, Interesting)

    by jandersen (462034) on Thursday June 29, 2006 @04:20AM (#15626405)
    Structured coding has so far been the only really big thing in programming; anything else since then has just been fads. Structured programming made it possible to write code that was reasonably easy to follow logically - compare a badly structured COBOL or FORTRAN program to well structured C program to see what I mean.

    The things that have come in since then have been attempts at addressing minor shortcomings in the way people work; and not always very successfully. Compare C and C++: C is syntactically extremely simple, it gives you exactly what is necessary and nothing else. C++ tries to address the perceived shortcomings of C, mostly in the areas of reuse of code and initialisation of variables; but it comes at the cost of being an excessively complicated language and it requires a huge amount of self-discipline to avoid writing impenetrable, convoluted code.

Professional wrestling: ballet for the common man.

Working...