![]() |
Chapter 2 | ![]() |
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 |