Silly Assumptions

Contemporary software development requires a wide variety of skills, but people in many software organizations appear to think that team members can step into a new role and perform effectively simply by decree. The assumption is that anyone can become a requirements analyst, project manager, estimator, or tester—without any task-specific education or assistance. This can result in frustrated team members who are ill-prepared to perform well on difficult tasks. Let's look at some of these silly assumptions.

Requirements Development
Many people who attend my seminars on software requirements have a job title of business analyst or the equivalent. Other attendees, however, are developers, quality assurance staff, project managers, or product managers who are expected to perform requirements development as part of their jobs. Most of the people I meet who are responsible for requirements work have never been trained in how to do this aspect of their jobs. They just do the best they can based on their own experience.

Requirements development is hard! Even knowledgeable users and experienced developers need to understand the principles and practices of requirements elicitation, analysis, specification, validation, and management. Inadequate requirements are the typical consequence of expecting analysts to excel at this critical and difficult project role without the requisite knowledge, skills, and experience.

Project Management
John Boddie, coauthor of Managing a Programming Project: Processes and People , once said that all too often new project managers are promoted from the technical ranks with less task-specific training than McDonald's gives someone moving from french fries to hamburgers. I have encountered many people who were talented software developers one day and project managers the next. Sometimes they flourished, but sometimes they flailed.

Project management is hard! The skills needed to coordinate the work of multiple people differ from those needed Moving to project management involves a shift from day-to-day thinking about software implementation to a strategic view of moving the team toward a common target. Personality and communication style are also critical to a project manager's effectiveness. Don’t assume that solid technical leaders can instantly become good project managers—or that they necessarily want to.

Estimation
Nearly all of the software professionals I meet must generate estimates for work they do, but few tell me they've been trained in how to estimate. Is it realistic to expect people to generate estimates when they've received no guidance on how to do so?

Estimation is hard! Generating plausible estimates requires data from previous experiences and heuristics for projecting the size, effort, or duration of work yet to be performed. Effective estimators collect data from their current efforts to use for future estimation. They know various techniques for producing estimates and for translating effort estimates into calendar time. Experienced estimators also add contingency buffers to accommodate unforeseen requirements growth, erroneous assumptions, and inaccurate estimates. It's silly to assume that all software team members can generate highly precise and accurate estimates without being taught how to estimate.

Testing
I often ask seminar participants if they do testing for at least part of their jobs. Many hands shoot up because most people on a software project get involved with some aspect of the testing process. Next, I ask how many have ever taken a course on testing. Most of the hands go down. Finally, I ask how many have a book on software testing on their desks. Few hands remain raised. What's wrong with this picture?

Testing is hard! Anyone who is responsible for performing unit, integration, system, user acceptance, usability, performance, stress, load, or other types of testing needs to know what he's doing. Resource materials for software testers include