Chapter 4. The Software Team

Computer programming is a human activity.

”Gerald Weinberg [1971]

Key Points

• Effective requirements management can be accomplished only by an effective software team.

• Requirements management touches every team member, albeit in different ways.

• Effective requirements management requires mastering six team skills.

Individuals choose software development as their career domain for a variety of reasons. Some read Popular Science and Wired as kids , gravitated to the programming courses available in high school, majored in engineering or computer science in college, and thereby directed their lives down this specific technical path . For others, it was serendipity ; finding themselves at a place in space and time when the need for software was apparent, where they could participate in meeting that need, they gradually evolved into making a full-time commitment in the field.

In any case, it was the allure of technology that kept the flame burning: We love the bits and bytes, the operating systems, the databases, the development tools, the keyboard shortcuts, the languages. Who else but software developers could have developed the UNIX operating system? We are focused on technology, and that is our driving motivation. Perhaps because of an innate genetic tendency or perhaps because we skipped all the "softer" classes in college ”psychology, drama, or, even worse , English! ”we are generally focused less on the people side of our business and more on the bits and bytes. We tend not to party well, ^[1] and some of us have trouble relating to people outside of work, when there is no common technology substrate on which to base a discussion.

^[1] During an open house, for example, one programmer remained at his desk throughout the party, programming happily, even though his desk was in the middle of the party room. After finishing his work, he simply got up, arranged his desk, and left the building without a word to anyone . What is unusual about this behavior? In our industry? Nothing!

One result of this, which was further compounded by the simple single- user nature of the tools we used and the more limited size of the applications we developed, was the tendency toward software development as an individual activity. The programmer defined, designed, wrote, and, typically, tested his or her own work. Perhaps testers were around to help with the heavy lifting at the end, but the focus clearly was on individual activity. The "programmer as hero" was the common paradigm.