The Science of Debugging
Chapter 2


Chapter 2 - Project Planning


Contents:
2.1 What is Project Planning?
2.2 Project Phases
2.3 Development Examples
2.3.1 Generate Project Goal & Focus (Initial Requirement Generation)
2.3.2 Gathering Requirements
2.3.3 Requirement Review
2.3.4 Requirement Approval
2.3.5 Requirement Hand-Off
2.3.6 Final Approval (Beta Testing)
2.4 Administration Payoff.
2.5 Programmer Payoff

2.1 What is Project Planning?


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 its 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 section is about; 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 had better read this too though!

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. 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. Also, some of those who can code have no idea as to the processes that ought to be followed when you do write programs. I'd like to think that this treatise will help everyone who reads it, regardless of their programming skill, or lack thereof.



Index
1.2 How do I Debug a program? 2.2 Project Phases