SE News

Ward Cunningham coined the metaphor of technical debt in 1992. “Shipping first-time code is like going into debt,” he said. “A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid.”

For large software projects, using debt is often a wise financial strategy. But incurring debt is always a risk, especially if it is high-interest debt and you’re not paying close attention to the cost. The same is true of technical debt, and it applies not only to code but also to architectural design and even to requirements analysis.

What is your project’s analysis debt load? What’s the difference between good and bad analysis debt? What are causes and remedies for such debt? Mary Gorman and Ellen Gottesdiener explore the concept of analysis debt and consider strategies for prudent investing.

Mary Gorman/Ellen Gottesdiener

http://www.stickyminds.com/s.asp?F=S15549_ART_2

This report provides guidance for those who want to make the business case for building software assurance into software products during each software development life-cycle activity. The business case defends the value of making additional efforts to ensure that software has minimal security risks when it is released and shows that those efforts are most cost-effective when they are made appropriately throughout the development life cycle. Although there is no single model that can be recommended for making the cost/benefit argument, there are promising models and methods that can be used individually and collectively for this purpose, as well as some convincing case study data that supports the value of building software assurance into newly developed software. These are described in this report.

Nancy R. Mead
Julia H. Allen
W. Arthur Conklin
Antonio Drommi
John Harrison
Jeff Ingalsbe
James Rainey
Dan Shoemaker

http://www.sei.cmu.edu/library/abstracts/reports/09sr001.cfm

We’re now just past the 40th anniversary of the NATO Conference on Software Engineering in Garmisch, Germany, where the discipline of software engineering was first proposed. Because some of my early work became part of that new discipline, this seems like an appropriate moment for reassessment.

Tom DeMarco

http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

On many application development teams, the ongoing choices, actions, and practices of team members can have a negative impact on code maintainability and hence overall code quality. Until these issues are discerned and tended to, they will become more and more costly, in terms of increasing the time required to perform changes and in ongoing developer resource cost. Further, risk of regression defects increases when code maintainability is compromised, because code that is not properly maintained is inherently more brittle.

This article underscores the importance of code maintainability for application owners and development teams, describes the future impacts of neglecting code maintainability problems, attempts to impart an appropriate sense of urgency for resolving such problems where they are found, and presents some proven solutions.

John Elm

http://www.ibm.com/developerworks/rational/library/edge/09/jun09/designdebteconomics/index.html

The world is becoming more dependent on software delivery efficiency and world economies are becoming more dependent on producing software with improved economic outcomes. What we have learned over decades of advancing software development best practice is that software production involves more of an economics than an engineering discipline. This paper provides a provocative perspective on achieving agile software delivery and the economic foundations of modern best practices. It presents our view of the Top 10 principles in managing an industrial-strength software organization and achieving agility at any scale of business challenge.

Walker Royce

http://download.boulder.ibm.com/ibmdl/pub/software/rational/web/whitepapers/Royce_SoftwareEconomics_whitepaper3.pdf

Typically, information technology ranks highly among most companies’ top five expenditures. Yet IT continues to be one of the least understood and most poorly managed areas in business. While all executives recognize the importance of technology as a means of improving customer service and of making work more efficient, few understand how to leverage IT strategically and how to use it as a driver of business success. Managing IT as a Business provides executives with practical advice on how to unleash the full potential of this critical function so that companies can derive maximum benefit. It offers a proven plan for bridging the gap between CEOs and CIOs that has, until now, impeded their ability to work together in order to craft objectives, establish budget guidelines, and develop metrics for measuring IT value and success. In short, with this book as a guide, business leaders will learn how to manage IT as they would any other functional business unit.

Mark Lutchen

http://www.pwc.com/extweb/pwcpublications.nsf/docid/501f06413c9854b785256e1b0062002a

Value may accure by accident but not often. Professionals must intentionally seek to create value. Its easy for this pursuit to get lost in the day-to-day effort to meet deadlines and resolve issues. It is not an attribute that jumps out at you during development. It isn’t usually visible of its own accord until the product is completed and the absence of value becomes all too apparent and all too difficult to to fix.

John McGregor

http://www.jot.fm/issues/issue_2008_03/column1/index.html

In this comprehensive introduction to software measurement, Ebert and Dumke detail knowledge and experiences about the subject in an easily understood, hands-on presentation.

The combination of methodologies and applications makes the book ideally suited for both professionals in the software industry and for scientists looking for benchmarks and experiences. Besides the many practical hints and checklists, readers will also appreciate the large reference list, which includes links to metrics communities where project experiences are shared. Further information, continuously updated, can also be found on the Web site related to this book: http://metrics.cs.uni-magdeburg.de/.

Christoph Ebert
Reiner Dumke

http://www.springer.com/dal/home/generic/search/results?SGWID=1-40109-22-173740676-0

Architects must often make architectural design decisions but are typically unable to evaluate their economic impact. Management is often interested in product-level decisions (such as features and quality) but not in the technical details of how those decisions are achieved. These differing interests can lead to inconsistencies between how executives and managers define and foresee value, and how architects can enable or disable those value propositions through their design decisions. This lack of effective communication results in a weak partnership between architects and executives, resulting in missed opportunities to make informed and technically feasible valuedriven design decisions. This information exchange is particularly critical when an organization must plan for architecture evolution in the face of uncertain future business and mission goals. Since software engineering artifacts exist to serve the business goals of an enterprise, optimizing the value of software systems is a central concern of software engineering [Boehm 2000].

Equipping software architects with the ability to reason about value will provide them with the vocabulary and rationale needed to articulate the value-driven impact of architectural decisions to management.

Ipek Ozkaya, Rick Kazman and Mark Klein

http://www.sei.cmu.edu/publications/documents/07.reports/07tr003.html