Software Project Survival Guide

Text in black are quotes; text in green are my notes. I sometimes write in Spanish.

• Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively. #

• Software projects succeed or fail based on how carefully they are planned and how deliberately they are executed. #

• Software projects have a set of basic survival needs that must be satisfied before it becomes possible for the project team to focus effectively on the project’s higher level needs. #

• This test is available in electronic form on the Survival Guide Web site. The site address is http://www.construx.com/survivalguide/. #

• They think that the best way to run a project is to hire the best people you can, give them all the resources they ask for, and turn them loose to let them do what they’re best at. According to this view, projects that run without any attention to process can run extremely efficiently. #

• An investment made in process at the beginning of the project produces large returns later in the project. #

• Successful project teams create their own opportunities to correct upstream problems by conducting thorough, careful reviews of requirements and architecture. #

• If you want to understand what software development is all about, you need to understand that the project team has to think through and make all the decisions in one stage before it can know enough about the next stage even to estimate the work involved in it. #

• Early in the project you can have firm cost and schedule targets or a firm feature set, but not both. #

• Success in software development depends on making a carefully planned series of small mistakes in order to avoid making unplanned large mistakes. #

• As Tom Gilb says, if you don’t actively attack the risks on a software project, they will actively attack you. #

• The French writer Voltaire commented that an essay was finished not when there was nothing more to add, but when there was nothing more to take away. #

  • Un ensayo está listo no cuando no hay nada más que agregar, sino cuando no hay nada más que quitar. Enfócate en ser conciso, directo, pero con la suficiente sustancia para atraer al lector. Edita, edita edita. Remueve lo que no agrega valor.

• The most difficult part of requirements gathering is not the act of recording what the users want; it is the exploratory, developmental activity of helping users figure out what they want. #

• Be sure the users understand that the prototype is “just a prototype.” One risk of creating a User Interface Prototype is accidentally raising unrealistic expectations about future progress on the project. #

• The problem with quick and dirty, as some people have said, is that dirty remains long after quick has been forgotten. #

• For life-critical software, a greater number of testers is required. The flight control software for the space shuttle used 10 testers per developer. #

• Testing is a means of discovering the quality level of a software system, not a means of assuring software quality. #

• An effective beta test program requires a great deal of coordination and typically diverts resources that could provide more quality assurance benefit if focused inside the organization. #

• Architectural work should begin when requirements development is about 80 percent complete. #

• Once you realize that the goal of architecture is to reduce complexity, it becomes clear that the architect must focus as much on what to leave out of the software as on what to put in. #

• The project plan should not assume the team will work overtime #

• The project team should plan to reestimate at several specific times during the project #

• “How does a project get to be a year late?... One day at a time.” #

• Working smart and hard is OK. Working hard at the expense of working smart is not. #

• The smart money is on too much design formality rather than too little. #

• Understanding the best way to explore the architecture’s risks depends on understanding the difference between “horizontal” and “vertical” slices of a system. Suppose you have an analytical system that generates five graphs. You can define sets of graphs, and you can edit, print, save, and retrieve them. A “horizontal” slice of the system would explore the same bit of functionality for each of the five graphs. For example, such a slice might explore the printing of rough versions of each of the five graphs. A “vertical” slice of the system would explore functionality for only one graph, but it would explore the bare-bones top-to-bottom functionality for that graph, including editing, printing, saving, and retrieving. #

• Creation of coding standards can be surprisingly contentious, but really the specific details of the convention matter less than the extent to which the convention is followed. #

• As a practical matter, if decisions are not made correctly the first time, you won’t get a second chance. #

• The more the pressure to change the software increases, the more important it becomes to address changes deliberately, or the project will slip out of control. #

• On a typical project, about 80 percent of the time is spent on unplanned rework. #

• The entire project team should treat driving the software to a releasable state at the end of each stage as its top priority. #

• It isn’t wrong to underestimate the project’s size or overestimate the project team’s productivity early in the project; it’s wrong not to find and correct those estimation mistakes later in the project. #

• If the project stakeholders don’t understand the reestimation plan from the beginning of the project, the development team’s reestimates will be perceived as slips. #

• Don’t let team members work in an unsystematic way #