Software Development Goals

There are two important goals for software developers:

  • Build the right software
  • Build the software right

Both goals must be met in order to be successful. Everything done during development should be aimed at one of the goals.

Build the Right Software

To build the right software, you need to thoroughly understand the needs of your potential customer. You can start with an analysis of the market. Is there an existing market that is not being fulfilled? Is there a potential market that can be created? If we build this thing can we effectively communicate to the customer that it does what we say and is of benefit to the customer? If you can answer those questions then you can proceed. The worst possible situation to be in is having a solution in search of a problem. First you identify the problem then create the solution. To summarize, the software must first meet the user's needs, not the needs of the developer.

Once a potential project has been identified, you need to determine the functionality required to meet the need. This is where careful requirements analysis is done. It's no talways possible to discover all the needed functionality up front. Nevertheless, the closer you get to a complete system, the better the chance of success.

In addition to system features, you need to develop an appropriate user interface. If the system is intended to be used by people with little knowledge of computer systems you have to design a UI appropriate to their level of skill. Likewise, if you are designing a system for professional IT managers, you need a UI that gives them the power and flexibility they need. The UI may also need to meet some industry or organization's standard, or, fit an existing model that uses terms the user is familiar with. You can't just roll out a stock UI with some wizard or library. You have to adapt the UI to the specific end user you are trying to reach.

The software needs to use the appropriate technology as well. Software developers tend to be two to three years ahead of the general public in their awareness of new computer technology. However, it takes time for technology to become accepted and if you get in too early there can be resistance to the software because the technology used has not had time to become widely accepted. Compatibility with standards is often more important to the customer than performance or functionality.

Finally, you have to determine the economics of the project. If you don't have sufficient funding to complete the project then it's best to not waste what resources you have on a useless system. Furthermore, it may be fiscally possible to build the software system, but if the cost exceeds the benefit to the customer, you won't be able to sell the system. Note that this applies equally well to in-house development. If the added benefit to your organization is less than the cost, it doesn't make sense to waste your resources.

In summary, the right software:

  • Meets a real market need
  • Has all required functionality
  • Has an appropriate user interface
  • Uses a reliable, appropriate technology
  • Can be built with a greater benefit than cost

Build the Software Right

To build the software right means to use reliable coding techniques and a repeatable development process. It is amazing how many software development groups end up with an ad-hoc, just get it done, process. If you don't have control of the process you'll never know what you built or how you built it and each project becomes more a matter of dumb luck than anything else.

Reliable coding techniques will produce software that does not lose data, has no logic errors, memory leaks or program crashes. Most experienced programmers learn to practice "defensive programming" where they check the validity of data before using it and sprinkle "sanity checks" throughout the code. Most importantly, the code must contain error-checking routines for return values. The old adage of "garbage in, garbage out" must be replaced with the principle of "garbage in, diagnostics out." These little blocks of code rarely affect performance, but if needed can be included only during development and removed in the final version. If possible, it's better to leave the checks in the code at all times.

Good code is efficient. It should not create an excessive burden on CPU, memory, storage, or communications devices. Although less important today that in the past, efficiency is still important. As developers we sometimes don't appreciate the scale of the user's enterprise. Software that works on a small data set used for testing may get bogged down when run in a "real-world" environment.

A software development organization must have and consistently use a coding standard. Each programmer tends to develop a preferred style of coding. Thus, if you ask ten programmers to produce a coding standard, you're likely to get back ten different standards. For this reason, the coding standard usually has to be dictated by the management of the organization and then rigorously enforced. Expect a religious war to break out when you create a coding standard. Nevertheless, it's very important.

Code reuse is another technique that can produce higher quality code. Once a function or module has been developed and debugged, reuse of that code helps not only to reduce the time needed for code development, but also helps to improve reliability. However, don't reuse code just to be reusing code. It takes discretion and a lot of experience to know when the code is appropriate to the current project. I have seen code where the programmer ended up writing more code in order to reuse a small function than he would have if he had just written the entire function.

The software must be maintainable. This means not only that it is documented in some fashion, but also that the algorithms and their implementation are easily understandable by subsequent developers. The more complex the code is, the more documentation it needs. Conversely, if the code is simple and obvious, don't waste time with extensive documentation. Ideally, the meaning of the code should be obvious to a programmer who looks at it. Document what is not obvious and otherwise let the code speak for itself. In order to be maintainable, the software must be written in such a way that it can be changed without breaking it. Watch for hidden couplings and carefully structure the code to get the best cohesion. Also, pay attention to the use of the system the software runs on. Can the environment (OS, hardware, UI, etc.) change without breaking the software?

Software built right is almost always portable. There are two types of portability. Most programmers understand the concept of portability between different platforms but overlook the second type of portability. The software must be portable to future versions of the operating system and libraries. To make software portable the software must be designed to isolate system dependencies so that changes in the platform only affect small sections of the code. Thus, portability is mostly a design problem and not strictly a coding or programming language problem.

Verify, verify, and verify. Test everything you can think of at all stages of the process. One common mistake programmers make is to write a large amount of code and then attempt to test the whole thing at once. The sooner you start testing, the better the end result will be. If at all possible, test each function or subroutine as soon as it is coded then test the interfaces between each subroutine. Sometimes it is necessary to build a test jig to test small portions of the code. The time lost to building the test system is more than made up for in time gained in testing and fixing the code.

As code is being developed, the build procedure should be created and tested. This allows doing a daily (or even hourly) build of the system. Using this constant build procedure allows detecting code that breaks the system as soon as possible after the incorrect code is produced. It is much easier to fix a problem immediately while the code is still fresh in your mind than to wait days or weeks to discover the problem and then try to remember what you did that caused the problem.

As soon as possible, a "clean-room build" should be set up. This is simply a computer that is set aside only for the purpose of building the system. Programmers tend to collecta lot of "junk" on their system and using a clean-room build insures that all the required pieces of code, and only the required pieces, get into the finished software.

Finally, building the software right means keeping track of what you did so that the process is repeatable. In addition, this allows you to do constant process improvement. There is no development organization that can't be improved. 

Links: