Low-Risk, High-Return Development  

order the book <<  

contact us <<  



For specific endorsements select one of the following links: AcademiaIndustryAgile


Barry Boehm, Ph.D.
Director, USC Center for Software Engineering
Creator of COCOMO and Spiral Model

Mark Denne and Jane Cleland-Huang's Software by Numbers is a significant new contribution to value-based, financially responsible software engineering. People and organizations looking for specific techniques to increase the business value of their software-intensive systems will find its Minimum Marketable Features and Incremental funding methodology techniques highly cost-effective to apply.


Carl K. Chang, Ph.D.
President IEEE Computer Society, 2004
Professor and Chair, Computer Science Department, Iowa State University
To succeed in today's IT environment we can no longer ignore the gap that exists between the vocabulary and value systems of business stakeholders and those of software developers. Successful software projects must not only be delivered on-time and within budget, but must fulfill organizational objectives and bring meaningful financial rewards. This can only be accomplished by managing business strategies as an integral part of the software development process. This book addresses the need head-on with analytical techniques, concepts, and tools to ensure that your corporation's software investment does not fall into the gap of cost overruns, finger pointing, late delivery and feature irrelevancy!

Industry  Back to top

An exciting new approach to software development that promises to deliver revenue sooner by applying analytical math to feature prioritization, can be snapped onto to either of the leading industry methodologies, and provides obvious opportunity for embracing the business in the feature-vetting part of the process.

Ron Lichty
Macromedia product manager for enterprise solutions
and recent emigre from Fortune 500 IT
Questions we faced as a startup: (1) How do we take advantage of our agility? (2) How do we maximize our sales potential? (3) How do we maximize our finite money and resources. Answer: Minimum Marketable Features. We wanted 4 products within 8 months. We completed 5. Our time to market is now 6 weeks vs 6-12 months.

Steve Quinlan
3Q Systems
Founder and CIO
Software By Numbers offers a rational approach to the often contentious process of feature prioritization by applying an objective mathematic framework to the process. Looking at prioritization based on ROI offers great opportunity for creating a dialogue between IT and business.

Laticia Miller
Deloitte Consulting
Project manager for business process outsourcing
Agile  Back to top

Alistair Cockburn
It is not often these days that a software book contains new enough information, captured in a different enough way, that I feel compelled to read it carefully and extract, to the extent I can, the knowledge of the authors. This is one of those rare books.

Two things struck me immediately, and a third almost half-way through my reading (well, page 50).

First, they *presuppose* that the project will be developed and delivered incrementally, and move forward from there. That is already interesting, since most authors spend their energies attempting to convince the reader to attempt incremental development at all. These authors provide information to convince those who don't know incremental development but want to stare at the arguments closely, and add relevant new information to those who already do know it well.

Second, they put numbers behind the agile approach of delivering usable functionality early. That is again only their starting point, and they move forward to show how some reasonably simple spreadsheet math points to a difference in *which* pieces get delivered first. (I focus on the presence of the agile style, since that is what I do).

Third (the one I discovered only half-way through my reading), they take into account financial consequences of incremental development of the *architecture* elements also, which I have never seen done before. (I and others recommend and do incremental architecture, but I've never seen a financial argument supporting the strategies). And again, that is where they start, and they move forward to derive which might best be developed first, etc.

Mind you, I'm generally allergic to looking at tables of financial numbers (and I'll guess most of you are, too), so it took some deep breathing exercises before I sat down with my cup of tea and worked my way through the first example on page 20. That activity was worthwhile, however, and I could see where they were headed (OK, overstatement again, they surprised me a few more times in the next 50 pages).

The book' material seems to have been derived from projects that were financially researched to a greater extent than the projects I've been involved in (read the preface for examples), so I don't know that I'll actually create a spreadsheet for my projects. However, the math and logic are compelling, and the spreadsheets are there for any financial officer or competitive bidder to use to examine the strategies for themselves. Maybe on my of my next projects, I'll draft someone to help me work through the math to see if our intuition matches the tables.

I can hope that as future work, these authors might take on two additional challenges: Include the "value of information" derived from a prototype or early increment, and show us how to fold those into the tables. Show how to work with coarse-grained valuations such as Tiny, Medium, Large, Humungous, and derive meaningful strategies from dependency networks of those.

Two last notes (I'd include some nifty quotes from the book, but this review is already long enough, so someone else can do that). First, perhaps a small point for some --- I rarely make it half-way through a book before getting too tired to take in more information, so I'm really glad they got the heart of their story in the first 77 pages (the grand denouement, incorporating XP, cost of money, and architectural dependencies all at once, is on pages 73-75 (not that you'll understand it if you don't read the previous pages)). They used the second half of the book for recap, extensions and examples. One of these days I'll have the energy to work carefully through their example on concurrent development. Second, their model suits both fixed bid and XP environments (and their discussion shows they understand modern agile development).

Tom Poppendieck
I picked up Software by Numbers at OOPSLA where a colleague described it as making the economic case for XP. Incremental funding of projects via minimum marketable features enables meaningful customer/management tradeoffs just a use cases enable user interface and workflow analysis and user stories enable reliable, predictable code development.  This is well worth adding to your customer toolkit for iterative incremental projects. It is systematically and broadly applies ideas similar to tool 12 in Lean Software Development, which describes using a project P&L to guide project decisions. Highly recommended.

Mary Poppendieck
Review at  http://www.poppendieck.com/funding.htm

Jim Shore
Software by Numbers describes a ReturnOnInvestment-based approach to selecting and prioritizing software features. The book includes an extensive discussion of its method, IFM (Incremental Funding Methodology), and guidelines on implementing it alongside RationalUnifiedProcess or XP.

IFM is a perfect fit for ExtremeProgramming: where XP addresses levels 1-3 on the LevelsOfSoftwareSuccess scale, Software by Numbers addresses levels 4-6. XP's simple approach to architectural dependencies (EvolutionaryArchitecture) looks like it'll make IFM even easier to implement.

Although some people may be turned off by the numbers-centric view, I loved the focus on DeliverValue and putting costs into context. I think this book offers guidance for OnSiteCustomers that XP lacks. Highly recommended. --