I just started reading this series. I saw the following comment in the "Beginning Game Development" article (first article), and I want to comment about this statement...

As we add more functionally to the game we will continuously do small design sessions to formulate our ideas. This iterative approach to developing software is the best way to create good software, and is more fun at the same time.

I've been a software developer for a long time, albeit not for games. At one point in my career I quit my job and spent three years writing and re-writing a desktop blogging application that I had intended to sell. I "knew" what I wanted to build, but approached the project with the same philosophy as quoted above.

In the end, I had a buggy, kludged-up application that I kept having to release patches for every week, and my app that was supposed to take one month to build and sell to the world for $20 a pop turned out taking me three years, having half of the intended features, and for a price of $10 before I ended up making it freeware.

Windows 95 followed the exact same philosophy, too, and we all know how that went. The Windows 95/98/ME series was a hodgepodge of bubblegum, rubber bands, and duct tape, wrapped in a colorful marketing package. It took Microsoft years of carefully planning out a proper system at the drawing board to reengineer Windows for the new (at the time) NT platform. NT was only successful, though, because of proper advanced planning.

Certainly, evolving a program as you build it is "fun" as such. But it is NOT "the best way to create good software," it is actually the absolute worst way when it is not the only way. Sometimes it's necessary as a discovery process. But it will rarely output "good software". Without a disciplined, thorough, even boring Phase One (functional requirements gathering phase) and Phase Two (software design and engineering requirements phase), you will see your ever-elusive release date constantly fading into the unforeseeable future, and your end product will be a mushy mess of compromises, bugs, and half-baked ideas.

No, do the dirty work of thorough early engineering before writing too much code. It isn't fun during that phase, but it's worth it. Believe me, my current job is with a business software company that makes me spend weeks doing "software development" in Microsoft Word by documenting a design specification. During these phases I experience such depression that I go home wondering if I should abandon my career altogether. But when the phase is over and I see how easily the design spec can be carried out by simply following the business rules I wrote in software speak, and everything works like a charm with no fundamental flaws, holes, or foundational bugs, I realize how important the whole process really is.

When it comes to games, certainly creativity is important, as well as evolution of the game. I think it's inevitable that a great game will require some evolution along the way, particularly as new major technologies come out for PC software every couple months. However, the statement "This iterative approach to developing software is the best way to create good software"could not bother me so much if it wasn't so untrue, from a technical point of view. It is an ideal statement, but it is simply not reality.

Sincerely,
Jon Davis