If you have developed large applications before, some of the following statements probably sound familiar. Most of these approaches start out with good intentions and are quite reasonable. However, these approaches often are unrealistic and can lead to delays, quality problems, and poor morale among team members.
"I have not really thought it through, but I think that we can complete the project in�."
Estimates made without planning rarely are accurate because they usually are based on an incomplete understanding of the problem. When developing for someone else, often you each have different ideas about the project requirements. To make accurate estimates, you both must understand the requirements and work through a preliminary high-level design to understand the components you need to develop.
"I think I understand the problem the customer wants to solve, so I can begin development immediately."
There are two problems with this statement. The first problem is that a lack of consensus on project goals results in schedule delays. Your idea of what a customer wants might be based on inadequate communication. Requirement lists and prototypes are two useful tools for clarifying project goals.
A second problem with this statement is that immediately beginning development frequently means writing code without a detailed design. Just as builders do not construct a building without architectural plans, developers do not begin building an application without a detailed design.
"We do not have time to write detailed plans. We have a strict schedule, so we need to begin developing immediately."
This situation is similar to the previous example but is such a common mistake that it is worth emphasizing. Software developers frequently skip important planning steps because planning does not seem as productive as developing code. As a result, developers create VIs without a clear idea of how the VIs all work together. Consequently, you have to rework code as you discover mistakes. Taking the time to develop a plan can prevent costly rework at the development stage.
"We can incorporate all the features in the first release. If the application does not include every feature, it is useless."
In some cases, this statement is correct. However, for most applications, developing in stages is a better approach. When you analyze the requirements for a project, prioritize the features. You can develop an initial VI that provides useful functionality in a shorter time at a lower cost. Then you can add features incrementally. The more you try to accomplish in a single stage, the greater the risk of falling behind schedule. Releasing software incrementally reduces schedule pressures and ensures a timely software release.
"If I can just get all the features in within the next month, I can fix any problems before the software releases."
To release high-quality products on time, you must maintain quality standards throughout development. Do not build new features on an unstable foundation and rely on correcting problems later. This development technique exacerbates problems and increases cost. Even if you complete all the features on time, the time required to correct the problems in the existing code and the new code can delay the release of the product. Prioritize features and implement the most important ones first. Once the most important features are tested thoroughly, you can choose to work on lower priority features or defer them to a future release.
"We are behind in the project schedule. We need to increase the number of developers working on the project."
In many cases, increasing the number of developers actually delays the project. Adding developers to a project requires time for training, which takes away time originally scheduled for development. Add resources earlier in the project rather than later. There also is a limit to the number of people who can work on a project effectively. With fewer people, there is less overlap. You can partition the project so each person works on a particular section. The more developers you add, the more difficult it becomes to avoid overlap.
"We are behind in the project, but we still think we can get all the features in by the specified date."
When you are behind in a project, it is important to recognize that fact and adjust your schedule. Assuming you can make up lost time can postpone choices until it becomes too costly to deal with them. For example, if you realize in the first month of a six-month project that you are behind, you can sacrifice a planned feature or add time to the overall schedule. If you do not realize you are behind schedule until the fifth month, you can affect decisions that other developers on your team made. Changing these decisions can be costly.
When you realize you are behind, adjust the schedule or consider features you can drop or postpone to subsequent releases. Do not ignore the delay or sacrifice testing scheduled for later in the process.
Numerous other problems can arise when developing software. The following list includes some of the fundamental elements of developing quality software on time:
Spend sufficient time planning.
Make sure the whole team thoroughly understands the problems they must solve.
Have a flexible development strategy that minimizes risk and accommodates change.