The Stages of Application Development

This chapter assumes you can already program or you can get another book to help you to learn. But what many new programmers forget about, especially those who have not been formally trained, is to take a step back and look at their application development project in context and to plan for future situations. Too many programmers are continually putting out fires, reinventing the wheel, and generally making poor use of their time, all while blaming project managers, users, and everyone else around them. Of course, others may not be blameless, but because this book is targeted at MySQL developers, I'll make a number of suggestions aimed at improving the way developers run the projects in which they are involved. Web developers in particular, who've often progressed through learning HTML and JavaScript up to MySQL and a programming language, are not aware of the complexities of larger projects and often get caught when projects get big.

The following sections briefly discuss the stages of application development. It is not a rigid prescription of steps; rather, it's one of many possible frameworks. Any good application development will allow a level of flexibility depending on the resources available and the specific conditions of the project. There are many good development methodologies, and you should use one appropriate to your needs, although the general principles usually remain the same. Reading this chapter in conjunction with Chapter 9, "Database Design," will help you grasp the bigger picture.

Phase 1: Analyzing the Requirements

Analyzing the requirements of a project is an obvious step in developing an application. This rule is repeated time and time again by experts bemoaning the poor state of software development. Yet all too often, "We didn't know you wanted that" or "You never told us that at the beginning" is offered as an excuse for the poor outcome of a project. The first and possibly most important phase of a project is determining its requirements.

Determining User Requirements

Most requests that users make are trivial, often much to their surprise. I've encountered users who, after dealing with incompetent or lazy developers, are terrified to make a request that turns out to be no more complex than an extra field in a table. In most cases, anything is possible as long as it's requested upfront. The main difficulty is not in fulfilling the user requirements, but in fulfilling different requirements after the original framework has been built. Users do not always know what they want. They need to be helped to formalize their requirements. But, seeing as this book is aimed at developers, not business decision makers, I'll place the burden on the developer. Make sure, upfront, that the user requirements are clear, understood by the development team, and understood by the users themselves.

The project team needs to undertake the following when determining user requirements:

• Engage the users to determine their requirements. Guide the users, explaining why certain suggestions are not practical or suggesting better alternatives. The team needs to use their experience. Bring unsaid requirements into the open so that they can be documented. What's obvious to the user may not be obvious to the developers, and important requirements may go missing. Requirements need to be as complete as possible. For example, a user may request that a reservation system "take the booking." However, this is no good. Each field is required for a booking, and the processes behind it needs to be spelled out.

• Once you understand the user requirements, write them down and return them to both the users and to the project owners (the people paying for the project) for confirmation. Users need to be sure what they are going to be getting; there should be no surprises later.

• Get the owners to sign off on the requirements. That way, there is less likelihood of either party being unhappy. Scope creep—when a project's requirements continue to grow during development—is an insidious problem that occurs frequently, usually when the requirements have not been formally agreed upon beforehand. Either the project owners demand more and more or someone from either party discovers critical new issues that no one thought of until then.

Determining Technology Requirements

Determining the technology requirements is as important as determining the user requirements. It may not be impossible to run a database-intensive website that gets more than 20 million page requests a month on one server, but at the least it's going to require a fine machine and specific conditions. The team should not impose any requirements on the project, for example, "It should run Linux and MySQL." The reason the technology requirements are listed afterward is so that the technology can best match the project—within any constraints. Questions to answer include the following:

• How many machines? What kind of architecture is needed to link them?

• What kind of machines do these need to be?

• What operating systems, DBMSs, or other software is required (such as web servers, mail clients, and so on)?

• What languages will be used to develop the application? Will they be object oriented?

Phase 2: Designing the Application

Once the requirements are crystallized, it's time to begin designing the application.

Modeling

A model simplifies the program structure and transforms the user requirements into a form that the programmer can easily understand. These can be formal models, such as required by Unified Modeling Language (UML), a data flow diagram, or simply a drawing on a piece of paper. The basics to include are what data each process needs and what data the process produces.

Using Pseudocode

Pseudocode is another step that can help the programmer develop an application more quickly and more easily. Instead of worrying about the exact syntax requirements of the programming language, pseudocode tackles the logical requirements, creating the algorithms needed to solve the problems.

Phase 3: Coding

This is the step that is often the only step. But coding becomes much easier when the documentation produced in the previous stages exists. Use the following tips during the coding phase:

• Always document your code. Include comments inside the code, and create separate documents noting how the application is put together and how it works. If not for yourself, do this for anyone else to follow you. (You'll be surprised how easy it is to forget some "trivial" detail after a few months.) A coder is selfish if they have not left ample documents for someone else to follow. Make sure you build in time for this, though; don't let the pressure of a deadline make you skimp on this aspect.

• Use clear filenames, function names, and variable names. For example, the function f3() is not very intuitive, but calculate_interest() is clearer.

• Don't reinvent the wheel. There are ample classes and sample code available. Rarely will coders need to do something unique. Mostly the job is repetitive, and coders play the job of librarian, tracking down the right code for the job.

• Initialize all your variables and document them in one place, even when coding in languages that allow variables to be used before they are initialized. This is not only more readable, but it is more secure.

• Break your code up into small parts. This makes it easier to understand, easier to debug, and easier to maintain. In web development, for example, some sources have espoused the virtues of one script to handle everything, and the result is usually a jumbled mess.

• Use directories intelligently. All parts of the application do not, and usually should not, appear in the same directory. Group them logically and for security purposes.

• Reuse your own code. Know what functions and classes have been created, and use these again and again. Write them so that they can be used for slightly different tasks. This makes changing code at a later stage much easier. This applies especially to things such as database connections.

• Separate logic from presentation (in a web environment, HTML and scripting languages are intermingled too frequently).

• When debugging a query, it can help to run the query directly in MySQL and not through the application (I often display the query and then paste this into the MySQL client). This allows you to narrow down the error, so you know whether it's in the query you're running or something in the application.

• Get into the habit of closing connections (running mysql_close() in PHP) and cleaning up resources, even if you're working in an environment where this is not necessary. Web developers often struggle when making the move to other kinds of applications, as they're used to a tolerant web environment, where everything is cleaned up after the web server process is complete. Similarly, languages such as PHP are much less strict than languages such as C++.

• Simple code is good code. Writing a chunk of code on one unreadable line, just because you can, may make you look clever, but it just frustrates those who have to read your code later. Coders who overly complicate their code are failing to do what coders are supposed to do: simplifying complexities. Simple code is usually as fast, too. It can even be faster, such as when you use simple string functions instead of regular expressions.

• In projects with more than one coder, use coding standards. That way when members of the coding team work on each other's code, they will be more productive because it will take them less time to adjust to the new standard (or lack of it). Coding standards include such things as the number of spaces (or tabs) to use when indenting and variable name conventions (such as whether to use capitalization, for example, $totalConnects; underscores, for example, $total_connects; or no spaces, for example, $totalconnects). The standards could go so far as to prescribe the editor to use, because different editors could align code differently, making it less readable.

• Larger projects too need some sort of version control. This ensures that when more than one person works on a piece of code, their work does not conflict. Even one-person projects can easily get out of hand if, like me, you have a tendency to work on different machines and save versions all over the place. Larger projects can use something such as CVS or Visual SourceSafe (these can be found at http://www.cvshome.org/ and http://msdn.microsoft.com/ssafe/, respectively), and small projects can simply use a numbering scheme.

• Use prototyping if the project warrants it (especially if there are doubts about all the project requirements being set). Prototyping is where a model of the final system is developed, without all the functionality, and this is worked and reworked until the final system is ready. Prototyping demands more of a role from the users and can be used to make them feel more included.

Phase 4: Testing and Implementation

Never skimp on the testing phase! Deadline pressure may tempt you to cut down the scheduled three weeks of testing to one, for example, but this is bound to backfire. You should not look at testing as an unnecessary burden; rather, it's a vital part of fine-tuning the application and ensuring that it runs smoothly.

There are a number of kinds of testing:

Unit testing These tests ensure that each class, method, and function works properly in its own right. You need to test whether the returned results are correct no matter what the input; in other words, account for every possible scenario.

Integration testing These tests ensure that each unit works as it should when integrated with other units.

System testing The entire system is tested as a whole. This would include testing the performance of the system under load (stress testing), multiple users, and so on.

Regression testing These are the tests that take place to see if the fixes have broken any other functionality. It's extremely common for "quick fixes" to have unforeseen circumstances.

After you've finished analyzing the requirements, designing the application, coding it, and then testing it, you're ready to implement the application. You may want to roll out the application for a small group of users or a single office first, allowing you to deal with any unforeseen problems, or take the big bang approach and move everyone to the new system at a single point in time. Then, be ready to start this process all over again when users request new features.