Summary

On the surface, this discussion of software process models may seem to be off-topic in a requirements text. Assuredly, it is not. In the move from a waterfall model to the iterative model, we can finally dispense with the notion that requirements are fully discoverable and can be fully documented before development begins and that they can be fixed or frozen thereafter. It was an interesting theory, and it appeared to make life for developers more straightforward as they imagined their work could be built on an unchanging foundation. Unfortunately, it simply did not work. Requirements change, and to pretend otherwise is, at best, foolish. We must understand that requirements discovery and requirements management are full lifecycle issues. The more we discover, the more we discover, and the better we understand the system to be built. With this context behind us, we can now move on to discovering that which we need to discover about our impending system. And we'll learn how to manage requirements change in a way that will augment, rather than destroy, the foundation for our development work.

Chapter 4. The Software Team

Computer programming is a human activity.

”Gerald Weinberg [1971]

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.