 |
 |
|
|
|
|
 |
|
|
These two letters were printed in TechWeek; I wasn't sure if I was more surprised to see the first or the second actually make it into print. I was sorry to see TechWeek go, since it tapped into the things techies liked to talk about over free soft drinks. |
|
TECHWEEK LETTERS: SOFTWARE TEAM ROLES, BACKGROUND ARTA Hot-Stove Debate About Software (November 30, 1998) In his Log On article, "Baseball holds tips for project forecasters" (Oct. 19 issue), Bruce E. Fad compared software project forecasting to baseball. It is true that software project success rates and benchwarmers' batting averages are in the same ballpark, but I think the analogy ends there. Batting averages are low because the task is difficult, not because baseball players neglect the fundamentals of the game. Software development is also difficult, but the failure rates are high because the fundamentals are routinely ignored. To explain, let me draw analogies with the construction and movie industries. If construction crews routinely built homes and roads without blueprints, they would overrun their budgets and schedules, too. Yet time and again coding begins on projects before any design is in place. Release dates are put into business plans and press releases based on little more than wishful thinking. If people didn't bother with architects, our buildings would be unattractive, inefficient and poorly suited to their intended purposes. Yet time and again, little or no time is allocated for this important first step. When there is a designated architect, the role has more to do with data structures and algorithms than with form and function. If architects never talked to their clients before drawing up blueprints, building construction would be halted frequently to make changes based on client feedback. Yet time and again products are nearly complete before end-users ever hear about them. The consequences? Expensive last-minute changes and the delays they bring, products that nobody wants and projects that are cancelled for not meeting business goals. Aesthetics in software, if it is considered at all, is added on last and rarely part of the design. When designers are brought in, they often lack any kind of engineering background because companies regard it as too expensive to have anyone with an engineering background worrying about usability, aesthetics or fun. The film industry has the challenge of coordinating highly paid creative egos to produce a product that lives and dies based on how well the public receives it. It is not at all obvious at first glance that making a film should be broken down into the roles that are so readily accepted today. While it may not be obvious today what the roles for a software team ought to be, the need for such roles is obvious. For example, why have a director who has final say instead of a cross-functional team of studio executives? Someone has to provide leadership and a unifying vision, and that only works if it's a single person. For software teams, Fred Brooks advocated a role like the director's—he called them pilots—in his book The Mythical Man-Month. This book is decades old, but his advice is still ignored. In a film, it is remarkable how the recording of the images onto film is distributed among a director of photography, camera operators, lighting crews, lab technicians and entirely separate groups for effects and editing. And these people have nothing to do with the audio tracks. There is a great deal of specialization and clearly defined roles that carry from film to film. If films were made like software, the director would just assemble a bunch of people who had worked on films before, and let expediency and accident determine who did what, inventing the rules and roles each time. As an industry, we have taken as a given for far too long the idea that software projects must always be behind schedule and over budget. It is our standard business model to sell defective products, expecting users to pay for upgrades that fix the bugs. All-night debugging sessions leading up to a product's release are taken as signs of teamwork and dedication instead of as evidence of poor planning and immaturity. We could look at our industry's failure rates and compare ourselves to baseball heroes, relishing each success because success is so rare. Instead, we should recognize that our failure rates are too high, and challenge ourselves to do better. Need for Speed (October 16, 2000) I was just looking through the October 2 issue of TechWeek and I noticed the artwork behind the text [in the cover story]. I'm sure it looks cool on the designer's monitor, but it is well known that distracting background graphics interfere with fast reading. As much as I enjoy TechWeek, if I can't read your articles quickly, I'm not going to read them at all. Sorry to be blunt, but there are many other publications and Web sites that compete for my attention. And the editor's response: We didn't like the way the background art in our cover story looked, either. We intended for it to be much more subtle, but our printer made a mistake. We're sorry. |
|
|
Home About Services Philosophy Contact Site Map |
|