The Old Joel on Software Forum: Part 4 (of 5)

Schedule a large project

Joel talks about painless functional specs and all his advice seems to make sense but his example for WhatTimeIsIt.com is pretty simple. It still probably took him at least 2-3 hours to write the document.

I work in console gaming (PS2/XBox etc) and while I agree making a functional spec is probably important, giving all the details required to actually make a complete one it seems like it would almost require a year or more to functionally spec out an entire large scale console game. Even a small one could take several months. In fact take your average MS App and writing full detailed functional specs would take months.

And there in lies the problem. Is there such a thing as taking 4 to 12 months just for spec writing? Would any company support such a thing? In games, worse, until you've made it you don't know if it's fun so if you decide to spend X months specing it you might end up throwing most of that spec away if it turns out a basic assumption about where the fun is in your design is wrong.

That makes me wonder, do functional specs fit all coding displines or is this on of those 7 worlds cases Joel talked about where most people discussing coding are only taking about business based internal apps?

Any thoughts or comments? I know that I have never worked at a company that would allow that many months for functional specing and I'm not sure they are wrong in wanting to see something on the screen asap.

Gregg Tavares
Thursday, February 5, 2004

1. How long would it take to implement "WhatTimeIsIt.com' v. the amount of time spent writing the spec? Is the proportion an hour to a month, an hour to a week, etc? How many man hours do you expect it to take to write this game?

2. In general, the more detailed the spec, the better the implementation, especially if you're dealing with a lot of programmers.

3. In my experience, while it's difficult to write a good game, or book or story, the basic elements of plotting all need to be there on every level, so it's not completely impossible to tell if something is going to be entertaining or not.

Perhaps better than a spec is someone with a vision. The guy who does the Metal Gear games acts more like the director of a movie than a spec writer, he's available at all times and plays early versions and tells the developer what it is he's looking for. The programmers in turn would be more like artists - actors, set directors, screen writers - implementing it in their own way.

Non Sequiter: Is it me or are there a lot of guys in the video game industry on this board now? Does this represent a shift in the technology industry? A few years ago it was all .com's and web apps.

www.MarkTAW.com
Thursday, February 5, 2004

I work in console gaming too -- you just have to judge the level of detail of your spec. If you're trying to specify everything, it can't be done, especially for a game. It is different than most application software, for exactly the reasons you state. Game creation is intrinsically iterative.

I think you just have to balance the number of man hours writing specs vs. the number of man hours writing code properly. For games you should err toward a lower ratio, I would say.

Roose
Thursday, February 5, 2004

MarkTAW: Re #3, in general I don't think it is possible to tell if a game is entertaining unless you have something you can lay your hands on. It is impossible to tell from reading a spec whether it will be entertaining. That is why you constantly need demos and iteration.

Roose
Thursday, February 5, 2004

From your first post, you kind of give the idea that you would need to write the whole spec before starting to code.

My method of working would be something closer to writing a general spec without too much details first, then write a very precise spec of every part described just before the coding team gets to implement it.

And be sure that if you work without detailed specs, you will have the same amount of speccing to do, only during coding instead of in a calm, relaxed state, and you will end up with functionnal errors, so to speak, aka a product that doesn't do all it should as well as it should.

Renaud Martinon
Thursday, February 5, 2004

Reese: Oh, I agree. Any one detail could make a game suck. The spec can't really take into account the feel of moving a character around the screen for example. There's also a highly subjective nature to this - some people will love a Rogue Like, while others won't want to get into the detail and will want the graphics.

However, I still feel that there's a lot of stuff can be learned from the spec, or an overview, or more important, a face-to-face with the guy whose idea it is in the first place.

To paraphrase Lajos Egri in The Art of Dramatic Writing, if you understand plot, you'll be able to know before writing the game whether or not it's compelling.

Science fiction & fantasy author Michael Moorcock after having worked on a video game said that the video game designers were some of the best people he'd ever collaborated with because they understood plot better than most writers.

Regarding the size & scope of a spec, you may want to head over to rec.arts.int-fiction, which is dedicated to making text adventure games and other newsgroups dedicated to gaming. While these tend to be one-man shows and made by people who aren't professional programmers, they're really open about the experience of designing & programming a game.

Since these are text games, they can easily create "mockups" just by writing out what happens, and generally write the walkthrough to the entire game, draw a map, and so forth. By and large they say you need a complete "spec" before you start working.

Also, text games were used to prototype other games, I imagine other game making tools like Unlimited Adventures could be used to prototype some aspects of the game, if it follows adventure or RPG conventions to any extent.

I doubt there are hard and fast rules here though, I'm sure you'll hear stories of people flying by the seat of their pants and making good games, the same way you hear about programmers who never read. ;-)

www.MarkTAW.com
Thursday, February 5, 2004

Complete specifications are an absurd delusion, even outside the gaming industry. Too many people like to blame incomplete specifications for their own inadequacies. Try asking for clarifications instead. I know talking to living, breathing humans can be intimidating or frustrating, but give it a try. You can't expect to know everything up front, and if you're not learning something new about the problem space while programming the solution then you're not paying attention.

Our chief weapon is incremental development, incremental development and master programmers. Our two chief weapons are incremental development and master programmers... and a suitable environment. Among our weapons are...

veal
Thursday, February 5, 2004

veal: I agree, I also agree with Renaud Martinon. I couldn't imagine writing a single spec for MS Word any more than I could imagine writing a single spec for Grand Theft Auto.

If you measure breadth in units, and depth in units, expecting someone to write a 10 wide spec that's also 10 deep, with 10 units of clarification on each item is asking them to write 1,000 units.

It may look like a small 10 x 10 x 10 cube, but it's big.

Besides, it's an ineffecient use of resourses. There's no reason to have programmers sitting around for a year while the project manager writes the spec, and then have the project manager sitting around for a year while the game is being developed.

www.MarkTAW.com
Thursday, February 5, 2004

You might want to read 'Agile Software Development with Scrum'

In a nutshell: If Gannt Charts won't help you, it's silly to use them.

Matt H.
Thursday, February 5, 2004

Gannt charts are good for wasting a LOT of paper.

www.MarkTAW.com
Thursday, February 5, 2004

Since the game industry is becoming more and more like the movie business, it is not surprising that choosing a winning concept for a modern game is as hit-and-miss as choosing a good script for a movie.

In both cases, there are many ideas that still get made into a final product even though halfway through, everyone involved has to know that the end result is going to suck rocks. The problem is that by the time this realization is made, too much money has already been spent to justify scrapping the whole thing, so the crew just has to slog though to the end and cut their losses. I would hope that it's a pretty rare occurrence that "bad" scripts and game designs get made on purpose from the beginning, but surely, this too probably happens when people with pull try to help out friends and family...

Tim Lara
Thursday, February 5, 2004

>>Complete specifications are an absurd delusion, even outside the gaming industry. Too many people like to blame incomplete specifications for their own inadequacies.

You obviously never watched a move then? I suggest you pop any DVD you have, and read the notes given to the director. Those director notes explain exactly what the move is to be. Sure, I accept that “complete” specs are not possible...but you can get VERY close to the final product. The movie industry proves this time and time again.

>>Since the game industry is becoming more and more like the movie business, it is not surprising that choosing a winning concept for a modern game is as hit-and-miss as choosing a good script for a movie.

Yes, but a winning concept, and a functional spec as to what the movie will be are complete different issues. They are compete un-related. We can’t blame a rotten move on the fact that the move was designed before shooting starts! (the two concepts are not related).

There is NOTHING, I repeat NOTHING stopping one from getting the design correct BEFORE one starts to shoot the movie, or start the coding process. It really comes down to size, scale of the project, and what kind of budgets you have.

If you want a fabulous example of a functional spec, pop in the Matrix DVD (talking about the original one here). Now, read the directors notes. To anyone reading this post...please...go and do that. It will be a absolute eye opening experience. It is amazing what you can do with just plain old English and typewriter!

Now, tell me it is not possible to write a spec for a creative product BEFORE it is created? Fact is, that those director notes were done BEFORE the move is made. Those notes describe in PERFECT detail how the movie will be. I going to stress here PERFECT DETAIL.

There is absolute no reason why a spec for a game cannot also be written. I most certainly believe that making a move is at least as creative as game writing.

There is some issues in regards to harnessing creative ideas that people come up with during the development process, and thus I will concede that some provisions need to be in place. Creating software is NOT like creating a movie.

As for the concept do some spend more then 4 months writing a spec? I remember reading about when the apple Mac OS software was being designed at apple (we are talking early 1980’s here). I believe it was more then one year passed of developers arguing as to how things should work. In other words, the developers argued, changed, had creative sessions for at least one year as they hammered out the spec. They were VERY smart, and realized that the designs MUST be fixed before coding starts.

Of course, changing the software design on paper is a zillion times easier then after you have blown 14 months of developer time. So, now, who gets a more creative process? Who gets the ability to change the design? Without question it is far far easier to change the spces then the actual code.

Further, once you get the designs done, the code process is MUCH faster, and everyone feels more productive anyway.

After all, we are arguing here that we want the most flexible approach, and we want the freedom to be creative. Well, you get ZERO freedom if you change your designs after writing 12 months of code...in fact, you just painted yourself into a corner. It is VERY hard to change those designs after lots of code has been written.

The fact that the apple team COULD NOT agree, or decide on how things should be done was NOT a problem. The developers were FREE to change the designs since changing the design on paper is one heck of lot easier then changing it once you got 1 year worth of coding done.

I mean, why not let everyone change their mind until everyone is happy? Would not this great freedom to change ones mind at they please result in the best product? So, clearly using a spec in place of code will result in the best product. I want everyone to be able to change their mind as often as possible. I want to harness every possible good idea. Lets turns this into a free for all in terms of creative process. I mean, why say something cannot be done because a bunch of code has to be changed! To really let this concept work, then you have to let the whole process play its self out BEFORE coding starts.

A person can start to create building without a design. Perhaps for garage it can be built as you go along. However, if you decide all of a sudden you want a window...even that change can be a real hassle.

For a large building, the major designs parts need to be done BEFORE construction starts. The only reason why this is so is because design changes ARE MORE expensive AFTER you start construction. You can’t pull out those previous floors, or re-do the foundation after the building is done.

The same concept applies software:

Changes to the design AFTER coding starts is MORE expensive. If your project is only a month or two..then golly...you can likely get away with design and coding at the same time. The reason why you don’t need a details spec for a 1 month project is that design changes CAN occur without huge damage. (ok,l...now that stupid 1 month project is turned into a two month project...but not too much of a over run to kill the budget). This is kind of like adding that window to the garage after it is built. Certainly one can get away doing this...but it don’t prove that it is the right way to do things. And, for sure it would have been better to have a correct design first even when planning to add that stupid little window. So, even for smaller projects, one will find the outcome tends to be better when you DESIGN before you code.

And for sure, some movies will change the outcome, or even parts of the script as they go along. Sometimes, they even go back and re-shoot scenes (gee, that great for the budget..eh?). Often just changing one scene or one part of a move means that other parts don’t make sense, or have also be removed or re-shot. Often, when you look at deleted scenes on a DVD, you see 3 or 4 scenes that had to be removed together as they are related. Software seems to have this “related” problem also.

No, the world is not perfect, and we can’t have a perfect spec before we start coding...but I have to say, the more of a spec you get down on paper before you write you will find the product of a higher quality, less time wasted during development, and more on budget.

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Thursday, February 5, 2004

Albert. Great points.

The difference between movies and video games is that nobody's being paid during the time you're developing ideas. So while many directors storyboard every shot (Hitchcock, the Wachowski Brothers, etc), there isn't a crew of actors photographers and so forth sitting around doing nothing and waiting for you while you do this.

Though, if you have a pool of programmers to call on who will work on other projects while you complete your spec, then great.

Also, I read an early script of The Matrix. Between that script and the movie two scenes were changed, two pivotal scenes, and the changes made between the script & the final product changed it from being an okay movie (like the sequals) to being a great movie.

While any one detail can make or break a game, I'll say it again, a strong plot will go a long way towards acheiving your goals.

Watching the director interview on the disc for the movie Memento went a long way towards disabusing me of the idea that great works of art just fall out of the sky fully formed. I knew it intellectually, but I hadn't really internalized it until I saw that.

www.MarkTAW.com
Thursday, February 5, 2004

>The difference between movies and video games is that nobody's being paid during the time you're developing ideas

Yea,...you got that right.

I wish I could get paid a whole year to sit on big huge bean bags, drink lots of cool beverages and spend a whole year with the teams figure out how things should work BEFORE the code phase. Not everyone has those luxury like those apple guys did.

The reality is that most software projects don’t have enough funds.

Also, often there is stages between design, and coding. I been into some projects and then paused for as much as 3 days THINKING on how one part will be implemented. This occurred after considerable coding had occurred. However, while the next phase was clear, it was not yet designed.

So, yes...of course the software process mixes design, and coding. We have to do this as a matter of survival, and just don’t have the luxuries that some teams have.

I often have believed that some of the success of extreme programming (pair programming) is due to the slowing down of the coding process and give the developers more time to think/design. This additional think before code time shows up in increased productivity. While this example occurs during the development process, I think the real key is that extra time is spent on design. This is also why those specs are a great idea.

So, I did want to point out that making specs and designs BEFORE coding CAN in fact help the creative process. There is often this idea that writing out the the spec somehow inhibits the creative development process, or hand ties the developers. In fact, it generally does the opposite. It is just a matter of how much design time we have BEFORE that coding starts, and we don’t get that!

Also, writing out much, or most of the details can a be a real fantastic communication tool to the company you are working with. I had some functional specs used in meetings, and since the narrative was not technical at all, then the company was able to give some real input. In fact, parts of the narrative that pointed out what the software will NOT do proved to be the most valuable. The company agreed with most limitations, but a few limitations were NOT acceptable. It was then easy to get more budget for those additional features, and not some big surprise months down the road.

So, there are many benefits of having more designs up front then leaving them to later stages in the development process. Removing some surprises and getting a larger budget can often be the result of a functional spec!

The real trick is somehow getting paid to write those specs!

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Friday, February 6, 2004

Albert, I can't speak knowingly about the moviemaking process, so I'll take your word that they always start with a complete specification down to the last costume button. Software ain't movies, and as awful as most commercial software products seem to be, they don't have half the story faults and continuity problems of nearly any movie. We don't ask our customers to suspend disbelief so deeply as the movie sellers.

"Changes to the design AFTER coding starts is MORE expensive." No, that's false. That's a popular belief among the management field that, like so many other false notions, has drifted into popular delusion among large segments of the programming field. When you have good programmers using modern approaches and tools, you *can* change the software as easily as you could write a complete specification for that same change. What you *cannot* do with a specification is learn along the way with great surety whether what you've concocted will actually work.

veal
Friday, February 6, 2004

I think someone above (sorry, I don't remember who) hit the nail on the head. The issue is that we are making a product similar to a movie but we are not allowed to make them like movies. Movies have months for pre-production where they make the script and especially for effects movies they draw a zillion storyboards to detail out what needs to be done. During this time there is no or little staff, just the writers and storyboard artists.

For most games there is a whole team sitting around waiting for development to start and a publisher that can't have them just sitting around. Also, game schedules (1.5 to 3 years for the entire development) are much much longer than most movies. Most movies have a production schedule of less than 3 months (except for effects).

Supposedly Nintendo operates like a movie studio where a small team, 5 or less people, will make a game for 12 to 18 months figuring out the details. Only after they are finished with this *pre-production* do they then put a whole team for 20-30 people on production of the actual game.

Gregg Tavares
Tuesday, February 10, 2004