Unlimited Faxes, No Fees, Dedicated Phone Number
Reach your customers at any time & place Market on a one-to-one basis.
Free php, mysql & perl web hosting. 29 Free PHP scripts with 1-click installations.
One of the most or often overlooked part of writing a program is the design part. Most programmers I've seen don't really know or appreciate the process of designing a program or software before they code it. This especially happens a lot with small programs that have no commercial interest and with young budding programmers who are just taking their first step into the programming world. I thought this article would be helpful to programmers beginning, or thinking of writing an open source app in a more organized and professional manner. I know it can be a pain in the ass to design before you code because of all that enthusiasm to start hacking away at your keyboard, but I can almost guarantee you that the pros will outweigh the cons in the long run if you plan ahead your programs.
What I realized is that most programmers need up-most motivation to complete a project without problems. If you are a programmer or software developer working on a commercial project, money is the main motivation most of the time (I see hate email in my inbox already). If you are an open source programmer there could be other forms of motivation; personal or just plain love for the program. Seeing your program work, for one is a really good motivation; great in fact. Designing a program before you code is one way of achieving this 'high', fast. It may ensure the long life span of your program and may be able to help you build a good following of users and developers.
Long life span of your program could be achieved because when you see your program up and running, you have motivation to keep modifying and improving it. If your program takes a long time to get up and running you may just loose interest and work on something else. After all, programmers are human too, they need some sort of motivation to keep them going. Having a good number of users using your program proves to be a good two way relationship with the longevity of your programs. This is because when you keep improving your program and adding more features, more people are going to use it and when more people use it, you will definitely have more motivation to make it better. Once you already have lots of users and if your design offers good flexibility, you are going to get developers jumping aboard. This is my version of the circle of life. I read once in a book on open source; having a growing number of users switching to Linux from Minix while it was being developed, pushed Linus Torvalds to add major features to the early Linux kernels, like Virtual Memory Management (VMM) and networking for the x86. I am not saying that the factors I have given above are the key to the success of your programs, but it sure does help a lot.
I realized that when I designed or just sketched a program out before coding and followed it, I would almost always get the program up and running in the shortest time possible and not be strayed by unnecessary thoughts and ideas. It wouldn't be the fastest or most efficient code but it would be ready for a better design or optimization. The main point is that it would be up and running, and would be doing what it's supposed to do.
I used to be a programmer who kept his designs in his head but it did me no good. In fact, working without a design proved to be a better bet. The volatile and dynamic nature of your brain actually works against you; your design keeps improving in your head all the time and you may not complete your program in a given time. Sometimes you may even forget important pieces for a while and this may interrupt your flow while you code. Sketching out a design on something tangible like paper (which is the best and fastest way) keeps a static outline or path you have to follow. If you need to make an important change make sure you update it on your sketch. Always keep your design updated on paper, never keep anything in your head for a long time.The first design of your program need not be perfect and it usually isn't. Try to come up with it the best possible design within a given timeframe and don't be too anal in trying to make everything fit like lego.
The first step in designing your program is creating an abstract design. An abstract design is a program design that does not contain elements, structures and programming paradigms from a particular language. Using an abstract design, you should be able to replicate a program using any language, that is, after you come up with a main design for it. The purpose of an abstract design is to keep you on track towards the goal of your program. You also will use it as a blueprint to create a more detailed design of your program for the programming language you plan to use. Sometimes while creating a main design for your program you may loose track of your final goals, so your abstract design is something you can fall back onto. Your abstract design works just like pseudo code for your program.
You can use a specific modelling language like UML (Unified Modelling Language) or a flowchart to create your abstract design, but you don't need to. If you think a particular modelling language wont fit your criteria, you can always create your own. Think outside the box, be creative and innovative, use a combination of different elements from different modelling languages or why not create something totally new that only you understand intuitively. I suggest that you add a legend or describe what the elements in your modelling language mean, for others to understand. You could even use words and sentences to describe your program.
For example, I'm going to start by designing a simple game that most of us have come across in our programming endeavors, guess the number game. You have X guesses to guess a number between 1 and 100. If the number you input is smaller than the answer, the program tells you its is smaller and vice versa if its larger. If you guess the correct number in X guesses you win, else you lose. Simple? Okay lets create an abstract design for the program. The abstract design can be as simple as possible or as complicated as possible, but i suggest you go for the simple as possible approach. There is no right or wrong way to do it, but keep in mind that the point of an abstract design is to show the abstract subsystems of a program so you can code it in any language, and for new developers to get a little understanding of the overall program architecture. Below (Fig 1.1), is the abstract design I have created for this game.
The simple design was meant to keep the overall picture of the game. It doesn't show you how to actually code it, but what it does. The comments explain the subsystem or modules of the design and keep the diagram from being too ambiguous, because most programs have an input, check and output subsystem.
.JPEG)
Once you have created your abstract design, pick a language then come up with a more in-depth design based on the programming language you are using for the particular program. I recommend using UML (Unified Modelling Language) for object oriented based code, and by slightly innovating UML you could use it for procedural based code. A more detailed description of important parts could be modelled using a flowchart. Above (Fig 1.2), is the main design for the game. I have used a flowchart style design not only because this design is procedural based but very easily I can get a feel for the flow of the program. The design super-imposes more onto a C program but hey it would work for C++ and Java too. Although, if I were to code this program in Java, I would have used a UML diagram to reflect classes and probably the design patterns in Java. The main design shows where I would implement my logic and loop control structures. The main design not only helps you out, but new developers who may work on your program or modify your code. Most programmers could definitely read through your code and figure out what's going on inside, but your design diagrams or sketches would give them a better understanding of your program. Sometimes your program design can get too complicated and you definitely need a design diagram to get an overall picture of the interaction that goes on, or the relationships between classes. A design diagram is almost a must for programs like these.
A few months ago I had to work on an Eclipse based plug-in, there were no design diagrams or proper documentation, to make it worse, the classes had really funny long names and there were almost two hundred of them that none of new development team members wrote. Figuring the program out by reading code only was bringing the whole project to a halt, after creation of a design diagram finally the new development team understood something. So, you can see how design diagrams play an important part in software maintenance and upkeep too.
Continuing, once the main design is completed, you can start coding. Be assured, the designs you've created will guide you in your coding process. Through experience, I've realized that as you code, things you've never thought of begin to creep up. Only make important changes that strengthen the basic structure of your code first, then build-up from there. Documenting critical parts of your code as you go also is a very good idea. Most of the time when you code, you say to yourself that once you are done, you will put in the comments, but when you are done, you might forget earlier parts of the code. So if you are too lazy and most programmers are (I'm going on assumption here), just comment the confusing code as you go.
Designing before you code is something which every computer science student learns at the beginning of the semester, it may be something you do just because your CS professor says so and there might also be a dogma that if you don't do it, you are not a civilized programmer. I say, create design diagrams for your program but don't overdo it, that's when it becomes a hassle, creating sufficient design diagrams do help you while you code and everyone in the long run, give it a try.
Copyright (c) 2005 nmr.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
