HomeOur GamesOrderingNewsForumsNeat StuffAbout UsEmail Us

Find Us on Facebook

Developing Your Program -The Long Haul

Once you have a computer and a plan for what sort of program you want to write, it's time to begin the longest and most enjoyable phase: creating the program. At least this should be the most enjoyable part. Love of coding and developing software is almost a prerequisite for this business. You'd better like to program. You're going to be doing it for quite some time.

To build a serious, useful program from nothing requires a huge expenditure of pure will. It requires hundreds of hours of painstaking work, careful planning and meticulous execution. The more passion you have for the work and the more careful your preparation, the easier the job will be.

Planning On Paper

When a large software company starts a new program, many hundreds of pages of notes are taken before even a single line of code is written. The structure of the program is planned out in exacting detail. The modules are described, the flow of control is established, and the global variables are described.

You should try to emulate this example. A large program is difficult to develop and maintain even when the code is simple, elegant, and carefully commented. If you are careless, sloppy and your code turns into spaghetti, maintaining it becomes nearly impossible. Even small changes cause the code to break somewhere else, and figuring out exactly what procedures do becomes very time-consuming (even when you wrote the procedures yourself).

Before you begin your program, think about exactly what it will need to do and how you will go about doing it. Figure out what variable and structure types you will need and write them out on paper. Plan out what code modules you will need, and which sections of code will inherit/use what other sections. Write pseudo-code for the major procedures, planning out what steps the program will take to carry out its actions, and what order the steps will be taken in. If you're writing a game, plan out the whole storyline. If you're writing a utility, figure out what its features will be. The more organized your program is in your mind when you begin to write the code, the easier a time you will have writing it.

Finally, plan the order you will write the program in and what features will be implemented first. You should strive to have something up and running as soon as possible, and then add new features to the already functional program. This way, you can watch how your program is coming together and notice problems, rough spots, and bugs as soon as possible. The sooner you spot a difficulty, the easier it will be to fix.

An excellent book on the software design process is Dynamics of Software Development, by Jim McCarthy. This is a fascinating book, and although its main focus is on designing software as a team, it has a lot of useful information for any software design process.

Building the Knowledge Base

When you start your program, it is not at all unusual to find out that you don't know how to program everything you want to do. If you're porting your program from the Mac to Windows, you need to learn how to code Windows. If you write a utility, you may need to learn how to create and write to a file. Starting a game may result in a sudden need to learn sound and graphics programming. Programming is a constant learning process. The environments you work in are constantly evolving, and you will constantly need to acquire new skills.

When you need to learn a new programming skill, the first and best place to go to is probably a book. At least one book has been written about practically every aspect of the programming experience, and some things (like game programming) have been illuminated by many thick, expensive tomes. Whenever you need to learn anything about programming, either basic or obscure, go shopping at every decent sized bookstore you can find. Borders', I have found, often have excellent programming sections.

When you find books on the subject you're interested in, look through them all. There are a lot of very good books on programming, but even more awful ones. Look for a book that looks readable and matches your style.

Programming books are generally huge (500-1500 pages) and quite expensive (usually $30-60). It can be very tempting to skimp and buy as few of them as possible (especially if your budget is limited). However, try to get as many relevant books as you can. I generally say "You can never have too many books on programming."

It's almost always better to have as many books on programming as possible. Every book covers different topics and explains some things better than others. When you need to use a new system call, owning more books means you'll be more likely to have a book which explains that command well. This will help you conserve your most valuable and limited resource: time. Also, reading through programming books is a great way to be exposed to new system capabilites you may not have been aware of. The more things you know about (and the more books you own which explain how to do those things), the more you will be able to flesh out and improve your programs.

Finally, people often ask what the best books are for learning how to program Windows and the Macintosh. For Windows, the classic book is Programming Windows 5th ed (by Charles Petzold). For Macintosh, I strongly recommend Macintosh Programming Techniques (by Dan Parks Sydow, a truly remarkable technical writer). Both books are excellent and chock-full of programming goodness.

Designing Your Program

When planning your program, you will need to figure out how you want your interface to look and work, and you will need to determine, for the most part, what your program's feature set will be.

This is a good time to think about your users. What will they want from your program? How will they actually use it? How often will they run it, and how long will the sessions probably last? Will this be a program people actually want to use? Will they want it enough to pay for it? Ask the hard questions now, and look at your program idea with a skeptical eye. Make sure your program is something people will want before you write it.

It might help to find an online discussion area related to your topic (on USENET or an online service), write a post describing the program you want to write, and ask people what they're looking for in such a program. You can get a lot of good feedback and ideas by doing this and learn about things that will turn your users off.

Do market research. Find and try every program similar to yours you can find. After trying one, examine it carefully. Figure out what's good and bad about it. Look for good qualities you can emulate and pitfalls you can avoid. Make sure that your program will, in one way or another, be superior to every other similar program. This is also a good chance to see how much people are charging for similar programs.

Once your market research is completed, design your program. Be very careful with the interface. Make sure that it's as clean, clear, and simple as you can. Figure out what the most used features will be and make them the most easily accessable options. Bury seldom used features farther down in the menus. Try to minimize the number of mouse clicks the user must provide to do any one thing. Figure out how the user will find online help. Think about where the program will say that it's shareware and explain how to order.

Software is partially art and reflects the state of mind of its author. Keep your mind clear and organized, and your program will be clear too. If you don't focus and concentrate on what you want, your program will be muddled. Remember - a program will have to be very clean and usable before people will pay you for it.

Writing Your Code

In most good classes about programming (often available at your local college), the teacher will stress the importance of writing clean, elegant code. Your code should be as simple and brief as possible, and, when you read it, it shouldn't take much work to figure out what it's actually doing. The variables should have descriptive names (e.g. call a variable "high_score" instead of "h"). Procedures and blocks of code should be commented. While these techniques can be very annoying while taking the class and time-consuming in real life, they can be extremely valuable when trying to maintain and expand your own 50000 line program.

Your code should have clear, brief comments. There's no need to go overboard on this. A sentence or two at the begining of a procedure explaining what it does and what variables are passed into it should suffice. The key is to make it so that when you return to this code to fix something six months later, you waste as little time as possible figuring out what you were trying to do.

Your variables should have clear, descriptive names. By the time your program is done, you may well have hundreds of variables. If you have to spend time figuring out what they are and what they mean, it can take hours to decode a block of code. Do the same thing with your procedure names. If, in your arcade game, you want a procedure to increase the player's score, call it "increase_score", not "incscr".

Of course, all of these things are guidelines, not absolute rules. For example, for variables I use all the time, I generally use names which are quick and easy to type. In Exile, one bit of text I always used was "party.stuff_done." For later games, to save typing, I placed "#define PSD party.stuff_done" in the global definition file so that I could type "PSD" instead of "party.stuff_done." It was a variable I used often enough that I always knew what PSD meant, and it saved me a lot of typing time. As always, use common sense. If something works very well for you, don't abandon it.

I often suggest writing "simple, elegant code," without explaining what I mean. Elegant code is a concept that is hard to explain. It's sort of a "know it when I see it" sort of thing. Here's an example (in C), which uses two procedures (written elsewhere) "draw_rectangle_on_screen(short top,short left, short bottom, short right)" and "draw_number_in_rectangle(short short top,short left, short bottom, short right, short which_number)":

> begin code a <

void place_five_rectangles_with_nums()

// Draw five rectangles on the screen with numbers in the middle of them


draw_number_in_rectangle(10,10,50,50, 18);
draw_number_in_rectangle(20,40,50,70, 8);
draw_number_in_rectangle(1,5,8,12, 2);
draw_number_in_rectangle(100,110,200,250, 99);
draw_number_in_rectangle(200,220,300,350, 87);


> end code a <

> begin code b <

draw_rect_and_num(short short top,short left, short bottom, short right, short which_number)


draw_number_in_rectangle(top,left,bottom,right, which_number);


void place_five_rectangles_with_nums()

// Draw five rectangles on the screen with numbers in the middle of them


draw_rect_and_num(10,10,50,50, 18);
draw_rect_and_num(20,40,50,70, 8);
draw_rect_and_num(1,5,8,12, 2);
draw_rect_and_num(100,110,200,250, 99);
draw_rect_and_num(200,220,300,350, 87);


> end code b <

Both pieces of code are about the same length. Both do the exactly the same thing. Yet, the second piece will generally be much better. Why?

Suppose that every time the program draws a rectangle and number, you want it to also call the function "happy_beep()". In the first piece, you would have to place five "happy_beep" calls, once for each rectangle and number. In the second piece of code, you only need to place one "happy_beep", inside draw_rect_and_num.

Or suppose you want to draw more rectangles and numbers somewhere else in the code. In this case, draw_rect_and_num has already been written, and you can use it wherever you want. The breaking of commonly used tasks off into their own procedures is one of the hallmarks of writing elegant code. It makes your code shorter, simpler, and easier to maintain.

Back to Designing Shareware Page

horizontal rule

Copyright ©1994-2017 by Spiderweb Software, Inc. All rights reserved.