Table of contents

Measuring software development productivity is difficult, but it's not impossible. It's prone to misuse and misinterpretation, and highly portable, precise measures are elusive. But we can still implement meaningful measures, provided we understand why we're doing it and provided we're aware of their limitations.
View full abstract»

Getting the requirements right is one of the most important activities in software development. Making a crucial misstep at this phase can easily lead to large amounts of rework when the customer simply can't accept a system the way it was developed. When used correctly, approaches such as incremental development or agile methods can mitigate the risks of getting the requirements wrong by making s...
View full abstract»

The next time you find yourself struggling with the details of your software's functionality, back up and tell a story. Talking through simple user scenarios can help keep you on the right track.
View full abstract»

As the code written today becomes part of tomorrow's inexorably growing pile of legacy, preserving these stories becomes increasingly important. It's costly to rely on informal storytelling to preserve and communicate important decisions; it's incredibly costly to try to recreate those decisions and their rationale when the storytellers themselves are gone. Insofar as a software development organi...
View full abstract»

Fred Brooks argued in 1986 that, for various reasons, no software engineering silver bullet would be found in the next decade. I argue now that the main reason that there can be no software engineering silver bullet is that as soon as one is produced, we software engineers move on almost immediately to solve even harder problems for which the silver bullet does not help much. That a silver bullet ...
View full abstract»

Jon Bentley wrote his thesis on divide-and-conquer algorithms and came to greatly admire C.A.R. Hoare's original quicksort algorithm. Yet for years, Bentley "tiptoed around its innermost loop" because he didn't understand it (Beautiful Code, O'Reilly, 2007). It was only after he implemented his own quicksort based on an elegant partitioning scheme for programming Pearls (Addison-Wesley, 1999) that...
View full abstract»

The elicitation, analysis, and specification of quality requirements involve careful balancing of a broad spectrum of competing priorities. Developers must therefore focus on identifying qualities and designing solutions that optimize the product's value to its stakeholders.
View full abstract»

Quality attribute requirements are important both for customer and end-user satisfaction and for driving software system design. Yet asserting their importance raises many other questions. In particular, using quality attribute information in practice isn't obvious. Here, we consider two aspects of using such information: communicating with stakeholders about quality attributes and incorporating q...
View full abstract»

When quality requirements are elicited from stakeholders, they're often stated qualitatively, such as "the response time must be fast" or "we need a highly available system". However, qualitatively represented requirements are ambiguous and thus difficult to verify. The value-oriented approach to specifying quality requirements uses a range of potential representations chosen on the basis of asses...
View full abstract»

Would slightly better performance be significantly more valuable from a market perspective? Would significantly better performance be just slightly more expensive to implement? When dealing with performance, usability, reliability, and so on, you often end up in difficult trade-off analysis. You must take into account aspects such as release targets, end-user experience, and business opportunities...
View full abstract»

Although detailed information is typically scarce during a project's early phases, developers frequently need to make key decisions about trade-offs among quality requirements. Developers in many fields-including systems, hardware, and software engineering-routinely make such decisions on the basis of a shallow of the situation or on past experience, which might be irrelevant to the current a cons...
View full abstract»

Traditional software engineering jumps too quickly from high-level quality statements to design ideas. To be clear about design, we must add a step to quantify the quality levels required. Words are ambiguous and lead to misunderstandings. Compare ";I want a user-friendly system"; to ";I want a system that reduces the number of accidental errors made by novice users to fewer than five per 1,000 tr...
View full abstract»

This document- oriented approach to developing content- intensive applications uses markup languages to involve domain experts in development and to simplify application production and maintenance.
View full abstract»

Support for test-driven development [TDD] is growing in many development contexts beyond its common association with extreme programming. By focusing on how TDD influences design characteristics, we hope to raise awareness of TDD as a design approach and assist others in decisions on whether and how to adopt TDD. Our results indicate that test-first programmers are more likely to write software in...
View full abstract»

Effective Web services demand careful synchronization on various abstraction levels. The Business Process Execution Language supports modeling and executing business processes from both the user and systems perspectives. In this way, Web services application developers can use BPEL to orchestrate service interactions in a global system view and to manage individual interactions based on outside ev...
View full abstract»

XML is an extremely nifty format. Computers can easily parse XML data, yet humans can also understand it. By adopting XML, we can take advantage of the scores of tools that work on arbitrary XML documents. Common tasks like editing, validation, transformations, and queries become just a matter of selecting and applying the right tool.
View full abstract»

In software, we often talk about user requirements and system requirements. Most people know the terms: users give you user requirements, designers work from system requirements. The terms have entered our lingua franca. However, in my experience, people - stakeholders, analysts, and designers - often fail to differentiate the roles of these two kinds of requirements. Unfortunately, treating user ...
View full abstract»