The waterfall model of design.
The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!
When I was a kid, I used to go to sleep clutching a fairy-tale story book about dragons and knights and princesses and most of all, magic. As I grew older, those books went from fairy tales to comic books to sci-fi novels, to computer tech manuals. Come full circle, I found myself in college, skimping some on the computer science theory, and spending more time programming muds - teeming with dragons and knights, the infrequent princess and, of course, lots of magic. Of course, the magic was a bit different for me, since I was the one in charge of making it available by writing spells, or creating a wonderful new artifact. Sort of a wizard's wizard. Programming was itself, a wild, wonderful sort of enchantment.
It's been a while since that sorcery was new and untamed, but it still has an irresistible draw. Now, I'm a programmer professionally, and even though I still weave a spell or two, most of my conjuration has to do with databases, web transactions, and socket protocols. It hasn't been without it's own benefits though. Working in the 'Real World' has shown me that no matter how much I know about writing code, sometimes it's not enough. Not that I needed to learn more about programming, but rather I needed to learn about the whole development process for any piece of software, anywhere. After I did, I looked at what I was doing as a hobby - coding for muds - and realized that I could apply those techniques there too. The development cycle is the same whether you're writing daemons, or writing demons.
So, that's what this article is; a sort of watered down description of a development system, and some guidelines I've found helpful to morph 'new and untamed' into 'quick and unstoppable'. Better yet, this is for both coders and non-coding administrators alike. It would actually be more accurate to say that this is especially for the non-coding administrators, since they will benefit the most from this. Their coding staff will too.
|
|
|
The waterfall model of design. |
(or, 'Damn it Jim, I'm a programmer, not a mind reader')
Let me start by explaining that the focus of this part is not to teach someone how to do the actual coding, insofar as technique, style, etc. Instead, this is about everything else relating to programming - most especially all those parts that no school I know teaches; working in a group, planning, developing requirements....etc. Basically, how to program, as opposed to how to code.
What's the difference between coding and programming? For the purposes of this discussion, coding is typing in text, compiling it, and running it. Programming will be the planned and developed creation or integration of that code produced above, and all the social nuances that go with it.
Now, some of you may not have to deal with it. It's always convenient to be the sole programmer and head administrator of your mud. However, the trend I've seen over the last few years though is that people with no coding experience are running muds. This is fine, except that the people also have no programming experience, and don't take the time to figure it out. Still, some of those who can code still have no idea as to the processes that ought to be followed when you do write programs. I'd like to think that this article will help everyone who reads it, regardless of their programming skill, or lack thereof.
I'm not going into the age-old argument about whether or not non-programmers can or should run a mud. You can answer that question for yourself.
I like examples, so we'll start with one.
--- example ---
One particular mud I used to work on had an overriding fixation on a 'remort' system. Well, the head administrator was fixated, at least. As the only 'Coder' on at the time, it was sort of my obligation to add a remort system. So I asked, "What sort of remort system would you like to add?" "I have the _xxx_-mud codebase in the mud directory, look at how they do it, and make it just like that.", the head administrator replies. This statement was made many, _many_ times.
I did actually run through the other mud's code, and saw what it was like. It was a simple system, you are set to level 1, your stats are rerolled, you get a bonus which is divided between your 6 main stats (str, dex, con, wis, int, cha) and your secondary stats (hit/mana/move), and you keep all the skills of your previous class. Simple.
The problem was that it wasn't directly applicable to our current system. It generated the bonuses based on things we didn't have. It generated the stats and additions based on the other mud's balance system. It changed experience gain in ways that our system wasn't setup to do. Aside from code, this system worked because there was a world framework with these new super-beings in place. There were remort-level zones, and remort-level equipment, etc. In the end, many questions needed to be asked, and the system still didn't go in right, because in some cases I made assumptions when necessary, or 'did what I thought was right' based on the administrator's suggestion (which was "do what you think is right").
It was made worse because we had binary player files at the time, and I was starting to get sick and tired of converting those and the world files each time we made a minor tweak in the system. In the end, it took about 4 months of bickering to get it in to a point where it was acceptable, and another 5-6 months to make at least a few areas where the remorts could go so they wouldn't stop depopulating the monsters in the rest of the mud. In the end, almost a year, and by then, it was decided that this system is actually no good, and ought to be replaced. To date, no one has risked the same sort of player loss we saw with the change of putting the system in, to take it out.
---Fin---
Where did this project go bad? There were actually alot of flaws, but the fundamental one was in the design phase. That nonexistent one.
If you've never heard of it, there's something called the 90/10 law which relates to software projects. It states that you should spend 90% of the time planning, and 10% of the time programming. If you move those ratios around you start loosing time; in code rewrites, updates, conversions, bug fixes, future compatibility issues. This time should have been spent on new projects, but now is taken in just maintaining old ones. You're actually losing twice; old project doesn't work, and new project doesn't exist. Project planning is very important, and whether the notes end up on the back of a cocktail napkin, or on the ever present white board, matters not a bit - it's that they exist at all. To put it another way, for every 10 minutes you spend planning a large project, you potentially save an hour and a half (90 minutes) that you won't have to program, debug, convert or deal with problem issues.
That's the big payoff.
There's some other benefits too though. If you, as an administrator, expect someone to write code which meshes 100% with your ideas, you are fooling yourself. Especially if you give one-line descriptions. This sort of thing may work well in some of the rare cases where the code addition doesn't affect balance, or game play, but more often, it will not.
If you want your ideas to become reality, you will actually have to sit down and flesh out your proposed changes. Flesh it out some more. More. More! MORE!
This is because you're going to hand that write-up over to a person, and expect them to run with it. There's a buzzword for this idea, but it comes down to the fact that you have specified so exactly what is needed, that if you were to die/get kidnapped/drink until you vomit/vacation/quit, someone would be able to pick up where you left off, with no problems whatsoever.
"Why would someone need to do that? As the administrator, I'll always be around, I can always be contacted by email, phone, ICQ, aim, or on the mud itself! If there's a question they can ask me!"
Well, the point is not contact, but something that's called 'Requirement Approval' and its brother 'External Dependencies'. See, in order to design the program structure, you need to have a pretty good overall view of the system and all it's interlocking parts. If I was told that the remort system listed above should show all the classes a player has on 'who', I may actually have to rewrite parts of the system, and require a player file conversion. If I know about it before hand though, I can plan for it, and end up making just one conversion. No problem. What if you just expected it to work like that - how could I know to even ask the question about new formatting in the 'who' listing? It's great that you're there, and have the answer, but the question will probably never come up.
That's why you write down all the requirements you want, in as much detail as possible. A simplified design phase looks something like this:
Generate project goal & focus (initial requirement generation)
Gathering Requirements
Requirement review
Requirement Approval
Requirement hand off
Final Approval (beta-testing)
I said I like examples right? Well, here's another. We're going to walk through the design phase of a very small project, just adding a single spell to the game (a CircleMUD in this case)
Generate project goal & focus (initial requirement generation)
You as the administrator create your goal - lets say it's to add a lightning spell. You set which class has it, how much damage it causes, how much mana it uses (spell energy, like in Diablo). Then you go to step 2.
Gathering Requirements
You examine your project for missing and incomplete requirements - look there, you forgot to say it can only be cast outdoors while raining. Also, you didn't state if saving throws would lower the damage or negate it altogether. It would be neat too, if people with metal weapons and armor took more damage, or if they were in the water.
Requirement review
You and your software engineering team (SE team) get together and talk in a sort of informal manner about what the requirements are, and whether they are viable, what their impact is, and whether a suggested requirement is appropriate, clearly stated and consistent with other requirements. Your SE team notes that you haven't given your lightning spell a name (You decide on 'electric charge'). They want to nix the idea about the extra damage for metal equipment, because the items in the game don't yet have material-types and it would be difficult to convert and then add this to the system in time to affect it. You agree, and put 'add material types' as a possible future goal, and tell your SE team that it's going to need to be added, eventually. They also note that you'll need not 'mana cost' but max and min mana cost, as well as the change in mana cost by level, minimum position needed to cast the spell (sleeping/fighting/etc), and whether or not the spell is considered violent. You say 40 mana for max and min, and the change is 0, and that you must be either fighting or standing for it to work - of course it _is_ a violent spell.
Towards the end of your meeting, you realize that you never assigned messages for the spell - what it looks like to the caster, onlookers, victims, gods, etc. You write up a quick set of these on a notepad file, after all, it was a chat-room conference.
Requirement Approval
You take the results of your discussion with your SE team (and any other insights you may have gained) and write up a document which says specifically what you want. Your document reads something like:
"Add a lightning spell. level 20, for the Cleric class, costs 40 mana to cast which never changes for level or anything, does 25d1 + level of caster damage, half damage on save vs electricity. The name is "electric charge" and it can only be cast outdoors while raining. If cast in a water room, everyone in the room will receive electrical damage equal to the caster's level. This extra damage is negated if they make a (separate) save vs. electricity. It's messages will look like this;
($_x_ is shorthand for the name replacement system in CircleMUD. $N = name of victim, $n = name of caster, $M is her/him/it…etc. These messages are CircleMUD's stock messages for the 'call lightning' spell)
Your lightning bolt kills $N!
You are electrocuted to death by a lightning bolt sent by $n!
The dead body of $N sizzles in the heat from a lightning bolt sent by $n!
Your lightning bolt scores the ground in front of $N, a misser! : The ground before you is scored as $n misses you with lightning!
$N jumps backwards in time to avoid lightning sent by $n!
You hit $N with your lightning, bullseye!
You are hit by lightning sent by $n, OUCH!
$N screams in pain as lightning from $n penetrates $M!
$N stops your lightning with a single gesture, BEWARE!!!
You stop $n's lightning with a sure hand, no time for children's games...
$n's lightning disappears as $N makes a simple gesture.
Everyone hit with the extra damage from the water will see an additional message stating "The water makes the electrical charge more severe!"
Of course, this spell cannot be cast in 'peaceful' rooms, and the caster can cast it only if they're standing or fighting.",
After you give your document to your SE team, they have one last chance to make suggestions, etc. If there is some point of contention, you have to go back to the top of this step (4) and start again. Once they agree to it though, then it's their job to put it in. This is the next step
Requirement hand off
So, you've done quite a bit of work. That write-up alone is a half page long, and it took a while to decide on the specifics. Now, your programming staff has the arduous job of putting all that information into the works. Looking at the write-up though, I would estimate that adding this spell would take around 5 minutes. It's so complete that I don't have to guess at anything. I don't have to take my best guess, or spend time tracking the administrator (you!) down, or much time debugging the code for intended results. It sounds mindless, and it is. It ought to be. Well, not that writing code is mindless, but that they shouldn't have to be creative and inventive inorder to fill in missing gaps so far as what this new project should actually do. After several years of programming, I can assure you, even simple additions tend to require a decent amount of intelligent thinking.
Now, your programmers put in the spell. When your house is carried to the land of Oz, and you're whacked in the head for a week, they can still plug away with little concern. After all, you've handed them the requirements. Your part is done!
Final Approval (beta testing)
It sounds so… final.
Final approval is something that you give after the coding staff says "Done". This step is tricky, because it can be both the shortest and longest step, depending entirely on what's being written. If the change is something like changing the splash screen of your MUD, it should be easy to determine if the people putting the change in have done what they were asked. Oftentimes though, a programming change needs more in-depth validation. Beta testing sometimes lasts months, or more. You have two goals in this phase:
Make sure that everything that was agreed to has been performed
Make sure that you haven't missed anything.
The first is self-explanatory, but the second comes up often. It's not so much that you miss something, so much as change your mind after seeing it in action. That's not a problem. That's just what happens. You have to go back to step 4 though. Lucky for you that it's just a hop-skip-jump since everything else was approved previously. Just don't skip this step.
This is also a good time to heap praise on the programmers.
There are a few of you out there who may claim that this sort of procedure is exemplifies more than just a bit of corporate ideology. You're right too - it does. This is because the corporate ideal of spending the smallest possible amount of time and effort (ie, money) to achieve a goal is certainly an intelligent standpoint. After all, would you rather spend nearly a year fixing and debugging a broken project, or would you rather spend 2 weeks planning, and and 3 days writing the code which achieves it's goal the first time and needs no later modification?
If you picked the year project, go to the top of the page and start again. You missed something. (that something is called 'text'. You should read it.)
For the truly interested, pick up the book "Code Complete". It includes actual time/effort consumption studies by IBM and other large corporations and gives real world examples and statistics to back up what I say here about the development process. It's not the most exciting stuff, but it is useful. If you find it interesting, you may want to get "Debugging the Development Process" which I used as a followup. It's a bit more schedule oriented, so it may not mesh well with volunteer work, but it is still useful as a general tool for group-related activities, such as project design and implementation.
Code Complete : A Practical Handbook of Software Construction by Steve C McConnell. Microsoft Press; ISBN: 1556154844
Debugging the Development Process : Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams by Steve Maguire. Microsoft Press; ISBN: 1556156502
September 2000 Imaginary Realities, the magazine of your mind.
© Copyright Information