Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Improving Software Economics

Walker Royce is Chief Software Delivery Economist at IBM Rational.

Most organizations that depend on software are struggling to transform their lifecycle model from a "development" focus to a "delivery" focus. This subtle distinction in wording represents a dramatic change in the principles that are driving the management philosophy and the governance models. Namely, a software development orientation focuses on the various activities required in the development process, while a software delivery orientation focuses on the results of that process. Organizations that have successfully made this transition -- perhaps 30-40% by our estimate -- have recognized that engineering discipline is trumped by economics discipline in most software-intensive endeavors.

IBM Rational has had a twofold mission since the 1980s:

  • To bring software development best practices to our customers.
  • To participate directly on their diverse projects to learn the patterns of success and failure so that we could differentiate which practices were best, and why.

As the world has become more dependent on software delivery efficiency, our observations indicate that, among the most successful businesses, software production involves more of an economics than an engineering discipline.

Here's one essential distinction between engineering governance and economics governance. An engineering approach typically relies on precise up-front planning, whereas an economics approach relies on continual course correction -- like steering a boat -- toward a target goal.

Let's put this in terms those outside the software industry can relate to: Software project managers are more likely to succeed if they use techniques similar to those used in movie production, compared to those used conventional engineering projects, like bridge construction. Consider this:

  • Most software professionals have no laws of physics to constrain their problems or solutions. They are bound only by human imagination, economic constraints, and platform performance once they create something that will run.
  • Quality is best measured through the eyes of the audience. Most aspects of quality are very subjective, such as responsiveness, maintainability, and usability.
  • In a software project, you can seemingly change almost anything at any time: plans, people, funding, requirements, designs, and tests. "Requirements" rarely describe anything that is truly required. Nearly everything is negotiable.

These three observations are equally applicable to software project managers and movie producers. Both are professionals who regularly create a unique and complex web of intellectual property bounded only by vision and human creativity. Both industries experience a very low success rate, although we know that great movies are made every year, as well as great software.

The point is, most mature engineering disciplines learned the laws that governed their enterprises long ago. The construction industry learned to eliminate the risk of reinventing the laws of construction on every project. What emerged were enforceable standards in building codes, materials, and techniques, particularly for the architectural engineering aspects of structure, power, plumbing, and foundation. This resulted in much more straightforward (i.e., predictable) construction with innovation mostly confined to the design touches sensed by its human users. This led to guided economic governance for the design/style/usability aspects with standardization and engineering governance driving most of the architecture, materials, and labor. Therefore, building engineers understand that when design innovations occur during the course of aplanned construction project -- involving new materials, new technology, or architectural deviations -- they incur the same sorts of cost overruns and rework that we see frequently in software projects.

Agile software delivery approaches start projects with an ever increasing amount of the product coming from existing assets, architectures, and services. Agile delivery projects that have fully transitioned to a steering leadership style based on effective measurement can optimize scope, design, and plans to reduce this waste of unnecessary scrap and rework further, eliminate uncertainties earlier, and significantly improve the probability of win-win outcomes for all stakeholders. Note that we don't expect scrap and rework rates to be driven to zero, but rather to a level that corresponds to healthy discovery, experimentation, and production levels commensurate with resolving the uncertainty of the product being developed. Business needs innovation; success demands it. That's why we need economic discipline and governance to measure the risk and variance of the uncertain outcomes associated with innovation. After many years of observing and deploying software delivery principles and capturing a framework of best practices, we have concluded that reducing uncertainty is the recurring theme that ties together successful techniques.

Based on experience with hundreds of projects, we have adopted the more advanced economic disciplines of agile software delivery. Here are my proposed top ten principles for achieving agile software delivery success.

  1. Reduce uncertainties by addressing architecturally significant decisions first.
  2. Establish an adaptive life-cycle process that accelerates variance reduction.
  3. Reduce the amount of custom development through asset reuse and middleware.
  4. Instrument the process to measure cost of change, quality trends, and progress trends.
  5. Communicate honest progressions and digressions with all stakeholders.
  6. Collaborate regularly with stakeholders to renegotiate priorities, scope, resources, and plans.
  7. Continuously integrate releases and test usage scenarios with evolving breadth and depth.
  8. Establish a collaboration platform that enhances teamwork among potentially distributed teams.
  9. Enhance the freedom to change plans, scope, and code releases through automation.
  10. Establish a governance model that guarantees creative freedoms to practitioners.

Successfully delivering software products in a predictable and profitable manner requires an evolving mixture of discovery, production, assessment, and a steering leadership style. The word "steering" implies active management involvement and frequent course-correction to produce better results. All stakeholders must collaborate to converge on moving targets, and the principles above delineate the economic foundations necessary to achieve good steering mechanisms. The key outcome of these modern agile delivery principles is increased flexibility, which enables the continuous negotiation of scope, plans, and solutions for effective economic governance.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.