Jump to content
  • Advertisement
Sign in to follow this  
coldacid

Six Lessons from the "Mainstream" Software Industry

This topic is 4841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Six Lessons from the "Mainstream" Software Industry by Clay Dreslough
Quote:
Article Spoiler: On the whole, the games industry has always lagged behind the rest of the software development world in terms of "mature development processes." Government and corporate software customers often require information about a developer's level of maturity, such as CMMI (Capability Maturity Model Integration) certification. Some of this difference is useful, as it allows for more creativity and market flexibility in game development. And we shouldn't kid ourselves. Most software development that occurs outside the game industry has its own problems with time and budget overruns. Nevertheless, there are some lessons we can learn from the vast body of research into conventional software development...

Share this post


Link to post
Share on other sites
Advertisement
While game developers would certainly benefit from learning more about processes, I really doubt things like the CMM are the answer. See "The Immaturity of CMM" by James Bach.

http://www.satisfice.com/articles/cmm.htm

That GameDaily article isn't bad, but there really is nothing particularly insightful in there. And the final words at the end ... why not point to _real_ references, like books or research papers? Really lame for an article on lesssons that come from the "vast body of research into conventional software development".

[Edited by - nickelplate on August 6, 2005 3:13:54 PM]

Share this post


Link to post
Share on other sites
If I knew Fred Brooks well, and he had a birthday, I'd go to a silver smith and buy a silver bullet. Then I'd give it to Fred Brooks as a birthday gift.

Share this post


Link to post
Share on other sites
I've worked at a place where they tried instituting a CMMI model. It doesn't work. It's far too human-resource-intensive to be really efficient (it's good for development houses in places like India to say "oh yeah, we're CMMI level 5" - simply because they can afford the rather high overhead needed to run a CMM shop.

The current trend for software development seems to be leaning more towards an "agile" environment, and while "agile" and CMM can work together, you generally don't find that happening very often.

That point about iterative vs linear doesn't really make sense to me. Iterative development doesn't really help when you've got a very well defined problem space, and esspecially when you've got past experience in the same problem-space. Sure there's often quite a bit of new technology in games, but a simple prototype is enough to get past that "will this actually work" stage, and you can then get into the design phase proper.

To me, making a game is a lot more like making a movie. You wouldn't use an iterative process to make a movie - you write the script, edit it, perfect it. Then you film the movie - every scene. Then you do your CG stuff (maybe you can start that while the movie's being filmed). Then you go into editing. A game is very similar, in my opinion, and I can't see why an iterative process would help.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Yay, Arild is back!

Share this post


Link to post
Share on other sites
According to wiki, sale of desktop processors accounted for only two tenths of a percent while sale of microcontrollers was like 50%. Should I adopt the development process of a washing machine to my game? How many people are needed to code a washing machine? How does this differ from those coding airplane avionics? Tasks are all different all needing different dev. process suitable to the task using its resources efficiently.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by JD
Should I adopt the development process of a washing machine to my game?


If the process works better than your current process (or lack thereof) then you should adopt the washing machine development process.

Share this post


Link to post
Share on other sites
Quote:
Original post by capn_midnight
I'm convinced that ANY structured software engineering methodology WILL work. The problem is, no one actually uses them.


A monkey at a typewriter will, given an infinite amount of time, produce the complete works of William Shakespeare. So, in a sense, that process "works" - but who's going to sit a monkey at a typewriter and wait for a million years when there's far more efficient ways to produce "Hamlet"?

Just because a process is structured, doesn't mean it's any good. Like I mentioned above, CMM is OK if you've got a lot of human resources, because it's very paperwork and time-intensive. But if you're a small developement shop with only 2 or 3 people the overhead far outweighs the benefits. Even where I used to work with 120 or so developers, there was still a lot more overhead that we really needed.

I'm not saying we need to go back to the dark ages and just let one or two "heros" carry the project, but I do think you need to carefully consider the benefits of any given development process and make sure that it fits the needs of your project.

Quote:
Original post by Anonymous Poster
If the process works better than your current process (or lack thereof) then you should adopt the washing machine development process.


"No" process is still a process (it's just not written down and is more ad hoc). And just because a certain methodology works for building washing machines, why would that mean it'll work just as well for anything else? I think that was the point JD was trying to make.

Share this post


Link to post
Share on other sites
I work at a CMMI level 5 company and it doesn't impose as many limitations on the developer's workflow as you guys think. There is very little documentation that I as a developer have to create, other than the comments in the code, and occasionally design documents. The main goals from the process are to continuously document the software process, do peer reviews (a good thing anyways), learn from previous development cycles, and apply that knowledge to the process that will be used next cycle. CMMI level 5 acknowledges that a stagnant process eventually fails, and that it must be flexible, and if you aren't modifying your process between dev cycles, you are doing something wrong. We have staff to take care of all that documentation, so developers are free to do what they want, code.

So bugs are tracked (not by developers, but by peer reviewer facilitators) by type, severity, stage in the development, etc. The data is analyzed, showing that design bugs found in the later stages of development are the most costly, so more design reviews up front end up saving time in the long run. When you have data from previous projects to back up your claims, higher-ups tend to listen, and will schedule time for design reviews.

That's only one example, but IMHO this can only be a good thing for developers who are always complaining about tight schedules and lack of time.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!