In typical classroom environments in an academic setting, a software project is done by either one person working alone or by a small team of students. The student teams work
together on the same project for a semester or, occasionally, for an entire year. There is little turnover in upper-level computer science courses and, hence, it is relatively easy to have the same teams in class projects. Projects intended for graduate students, especially PhD students, will generally be larger and require more time, but the same team members are available.
In real-world software development projects, the teams are rarely kept together for the entire life cycle of a software system, usually with a major change after each release of the software, if not sooner.
There are several reasons for the relatively high rate of personnel changes in actual soft- ware projects:
• Project staffing needs change. More people may be needed to work during the coding or testing and integration phases than are needed for the initial requirements gather- ing activity. Often, fewer people are needed for maintenance, especially if the system is expected to have a short life.
• The project may continue for a long period. For example, NASA’s International Ultraviolet Explorer satellite was expected to produce scientific data for one year and, thus, the original software maintenance team was expected to work for at most one year after the satellite was placed into orbit. Instead, the satellite’s scientific life lasted for 19 years, producing as much scientific data and subsequent research in its last year of operation as it did in its first. Clearly, there were many changes in project person- nel during this time. Several well-known database systems have been in operation for more than 30 years. Keeping the same level of staffing as in the initial development is extremely wasteful.
• People change jobs. Many software engineers prefer to be associated with new tech- nology and leave projects after the technology used in a particular project ceases to be cutting edge.
• Companies lose contracts. Many organizations merge and business units are refo- cused. In an extreme case, companies go out of business. If a company was working on a project as a subcontractor that is now defunct, the project team will change. • People retire or have major illnesses.
• Product lines, and companies themselves, may be sold to new companies.
• New people are hired to bring fresh ideas and new technology skills into organizations. It is clear that most real-world projects have substantial changes in their personnel during their lifetimes.
Now that you understand that the composition of project teams often will change con- siderably over the life of a project, you might consider the ramifications of this relative instability for your own career as a software engineer. Clearly, you will need to be flexible, because different individuals have different learning styles and you will have to interact
with many of these different styles over time. For instance, you might be paired with an individual who always follows the written company policies to the letter, refusing to submit any organization-supplied form unless the sentences are grammatically correct. Another person on the project will use shortcuts, writing phrases and sentence fragments, whereas the other might write formal, proper sentences. Both approaches might be very effective for the person who uses them and you might have to interact with each type of individual. Of course, the final deliverable product will have to be grammatically correct and adhere to the organization’s standards. This is becoming even more important for safety-critical software, for security software, or for software for financial purposes, due to the likelihood that such software may be audited in the event of a software failure.
It is important to accommodate different personality and learning styles within a group and to avoid what James McCarthy of Microsoft called “flipping the bozo bit” (McCarthy, 1995). This colorful term refers to assessing a person’s opinions and suggestions as being irrelevant, because the person is a “bozo,” and hence their “bozo bit” is flipped (set to one). McCarthy (and I) believes strongly that this is a very bad idea. Be receptive to all ideas and consider them as being potentially reasonable, regardless of the source of the idea. Decide on the validity of an idea only on its merits. This will help make you a valuable team mem- ber and will make your team work better.
It is important to understand the differences between organizational cultures. Some organizations follow a rigid process, demanding that all procedures be carried out and all decisions be carefully documented. An individual who does not precisely follow the orga- nization’s procedures often will be ignored or given less demanding work.
Other organizations have much less formal structure in their process. They often give software development teams only the most general guidelines, with almost complete free- dom to perform the essential activities. This freedom occurs most often when the team has a history of completing its projects successfully and within budget. A NASA technical report by Mandl (Mandl, 1998) describes an effective software development team that used relatively few formal procedures but was able to produce actual systems. It should be noted that this team had many years of experience in its particular application domain. We will discuss this example of agile programming that preceded the “Agile Manifesto” in more detail when we describe agile project management in Section 2.10.
You should make the distinction yourself in the kind of organization you choose to work for in order to match your temperament with the organizational development style that is right for you.