The basic conclusions of the book are all sound, the principle of determining the cost and benefits of each possible combination of software components that can be built and choosing the most profitable is something no one can argue with. Charts and tables are in abundance, as the authors step through many scenarios, including situations where the most profitable path may not be readily apparent. They start by introducing the Minimum Marketable Feature (MMF), which is defined as the minimum chunk of functionality that delivers a subset of the customer’s requirements and is capable of returning value to the customer when released as an independent entity. This is also sensible and should be a fundamental principle of software development. However, despite all this sensible material, there are some major problems with the book, and it starts with the title. Before I even opened it, I looked at the cover and was skeptical. There is no such thing as low-risk software development, it is simply too hard to do. The end results are also unpredictable due to the rapid change in the markets, customer fickleness and intense competition, therefore the high-return segment of the title can also be questioned. A more sensible title would have been “…Lower-Risk Higher-Return Development.” The major problem that I see is that nearly all the authors do is based on the fundamentally flawed premise that you know the costs and time frame for development to a high degree of accuracy for every available option. For most (nearly all) development teams, this is not the case when the project is being considered. At that point, you are dealing with ball-park, (big-league, not little-league), cost and time estimates, with enough uncertainty to lead to significant overlap between the costs of the options. Substantial market research can help, but it can only indicate what customers will(might) want and will tell you nothing about what your competitors are doing. I do grant that if the cost and return numbers are hard, then their techniques are rock-solid correct and only a fool would ignore them. If you are one of the lucky ones and can express your costs of development, time to completion and revenue from sales to a high degree of accuracy, then this book is valuable. Of course, if you are already that good at projections, then you most likely don’t need it. If your numbers are not hard, then applying these techniques could be dangerous. Assuming hard data when there is none is an untenable situation and was one of the primary reasons for the dot-com failures.
Rating: 4 / 5
I am an advocate of Agile Software Development methods so I read this book with that bias. What I found was this book quantifies many of the ideas of agile development that before just made intuitive sense. The book explains the potential value of developing in small steps, and has a great discussion of how incremental development and architecture interact to affect return on investment.
If you are not involved in the financial side of planning software projects you may find yourself skimming through parts, but the general themes are ones that everyone involved in planning software projects will find interesting. (This includes developers in small teams.)
In most cases customers want you to build a software application to help them make or save money, and reading this book will help you to understand that.
Rating: 4 / 5
This book caught my attention because I was searching for a decent book on ROI and software development, and Dr. Jane Cleland-Huang was a professor at the graduate school I attended (I was never a student of hers and have never met her). Furthering my interest in “Software by Numbers” were the facts that it runs less than 200 pages and is from Sun Microsystems. In my opinion, most large technology works can be significantly shortened if the fluff is removed from them (who has time to read fluff?), and I view Sun as a respected firm that is involved with a lot of the technologies in my workplace. Maximizing financial return during the development of software is the main subject of this book, and the attempt of Jane and Mark Denne, her co-author, to show how to do so is a good one. Interestingly enough, the Preface of this text discusses how the authors arrived at the title “Software by Numbers”, and although this title is better than the others that their friends and colleagues suggested, because it is a bit too similar to the common expression “paint by number” (which can be an idiomatic expression for “easy” or “mindless”), I do not think it does the book content justice. ROI is anything but a simple subject. Multiple formulas exist for ROI to begin with, and return can be a subjective matter because it can involve a lot of assumptions. Quite a few financial tables are presented with the book material, and a cursory review of the accompanying ROI examples shows that there is a bit of explanation missing. Of course, there is a tradeoff here between conciseness and thoroughness, and explaining all of the assumptions made would probably not be appropriate for most readers. The authors start the discussion by stating that software development is a very difficult endeavor. The following portions of the introductory chapters explain well much of the language used throughout the rest of the book, such as minimum marketable feature (MMF) and return on investment (ROI). The authors then compare MMF-based ROI with classic ROI and discuss how to discover MMFs, how to determine their value, and how this all fits with incremental funding methodology (IFM). While there exists overlap between the architecture discussion and the content of “Architecture in Practice” (see my review for that text), the authors quickly move forward to discussing the delivery of valued features to customers and how parallel development of multiple MMFs is often well suited for meeting customer needs. Although the chapter on how to manage intangibles provides a much more simple explanation than books such as “Making Technology Investments – ROI Road Map to Better Business Cases”, the authors get their point across in a succinct manner. Similarly, the authors discuss how IFM can thrive when used with the (Rational) Unified Process and other more agile software engineering methodologies.
Rating: 4 / 5
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).
Why not 5 stars if I don’t find anything wrong with it? Because 5 stars would mean to me that really everyone should run out and buy it. This book is the (correct) start of a conversation with a more limited audience — it satisfies its intended purpose extremely well.
Read this book if you are an incremental-development devotee looking for the next level of understanding; or you have to interface to a financial guy(gal); or you are one such yourself.
Rating: 4 / 5
I read this book because Tom and Mary Poppendieck recommended it to me at XP Day 3 (Their book on Lean Software Development is a must read.). It is an important book because it places Return on Investment (ROI) at the heart of IT prioritisation and decision making. If your company is not doing this, then it will have lots of trouble with its IT projects. The book explains ROI and Net Present Value (NPV) and then presents a heuristic for delivering the optimal deliver of ROI. The heuristic depends on having groups of functionality with associated revenues (These groups are called Minimum Marketable Functions or MMFs). The book then presents a methodology for delivering optimal ROI that works with RUP or Agile. I’m tempted to try out the heuristic although I suspect that most decent project managers could work out the optimal delivery without the use of the heuristic (one of the approaches they suggest.).
The big question that the book leaves me with is “Where do the revenue figures come from?” The book gives an unsatisfactory single sentence answer along the lines that they are produced by marketing and the business.
Overall I liked the book, it is well written and easy to read. My one contention is that the RUP chapters comes before the one on Agile.
Rating: 4 / 5
#1 by Charles Ashbacher on April 24, 2010 - 8:02 pm
The basic conclusions of the book are all sound, the principle of determining the cost and benefits of each possible combination of software components that can be built and choosing the most profitable is something no one can argue with. Charts and tables are in abundance, as the authors step through many scenarios, including situations where the most profitable path may not be readily apparent. They start by introducing the Minimum Marketable Feature (MMF), which is defined as the minimum chunk of functionality that delivers a subset of the customer’s requirements and is capable of returning value to the customer when released as an independent entity. This is also sensible and should be a fundamental principle of software development.
However, despite all this sensible material, there are some major problems with the book, and it starts with the title. Before I even opened it, I looked at the cover and was skeptical. There is no such thing as low-risk software development, it is simply too hard to do. The end results are also unpredictable due to the rapid change in the markets, customer fickleness and intense competition, therefore the high-return segment of the title can also be questioned. A more sensible title would have been “…Lower-Risk Higher-Return Development.”
The major problem that I see is that nearly all the authors do is based on the fundamentally flawed premise that you know the costs and time frame for development to a high degree of accuracy for every available option. For most (nearly all) development teams, this is not the case when the project is being considered. At that point, you are dealing with ball-park, (big-league, not little-league), cost and time estimates, with enough uncertainty to lead to significant overlap between the costs of the options. Substantial market research can help, but it can only indicate what customers will(might) want and will tell you nothing about what your competitors are doing. I do grant that if the cost and return numbers are hard, then their techniques are rock-solid correct and only a fool would ignore them.
If you are one of the lucky ones and can express your costs of development, time to completion and revenue from sales to a high degree of accuracy, then this book is valuable. Of course, if you are already that good at projections, then you most likely don’t need it. If your numbers are not hard, then applying these techniques could be dangerous. Assuming hard data when there is none is an untenable situation and was one of the primary reasons for the dot-com failures.
Rating: 4 / 5
#2 by Steve Berczuk on April 24, 2010 - 9:25 pm
I am an advocate of Agile Software Development methods so I read this book with that bias. What I found was this book quantifies many of the ideas of agile development that before just made intuitive sense. The book explains the potential value of developing in small steps, and has a great discussion of how incremental development and architecture interact to affect return on investment.
If you are not involved in the financial side of planning software projects you may find yourself skimming through parts, but the general themes are ones that everyone involved in planning software projects will find interesting. (This includes developers in small teams.)
In most cases customers want you to build a software application to help them make or save money, and reading this book will help you to understand that.
Rating: 4 / 5
#3 by Erik Gfesser on April 24, 2010 - 10:34 pm
This book caught my attention because I was searching for a decent book on ROI and software development, and Dr. Jane Cleland-Huang was a professor at the graduate school I attended (I was never a student of hers and have never met her). Furthering my interest in “Software by Numbers” were the facts that it runs less than 200 pages and is from Sun Microsystems. In my opinion, most large technology works can be significantly shortened if the fluff is removed from them (who has time to read fluff?), and I view Sun as a respected firm that is involved with a lot of the technologies in my workplace. Maximizing financial return during the development of software is the main subject of this book, and the attempt of Jane and Mark Denne, her co-author, to show how to do so is a good one. Interestingly enough, the Preface of this text discusses how the authors arrived at the title “Software by Numbers”, and although this title is better than the others that their friends and colleagues suggested, because it is a bit too similar to the common expression “paint by number” (which can be an idiomatic expression for “easy” or “mindless”), I do not think it does the book content justice. ROI is anything but a simple subject. Multiple formulas exist for ROI to begin with, and return can be a subjective matter because it can involve a lot of assumptions. Quite a few financial tables are presented with the book material, and a cursory review of the accompanying ROI examples shows that there is a bit of explanation missing. Of course, there is a tradeoff here between conciseness and thoroughness, and explaining all of the assumptions made would probably not be appropriate for most readers. The authors start the discussion by stating that software development is a very difficult endeavor. The following portions of the introductory chapters explain well much of the language used throughout the rest of the book, such as minimum marketable feature (MMF) and return on investment (ROI). The authors then compare MMF-based ROI with classic ROI and discuss how to discover MMFs, how to determine their value, and how this all fits with incremental funding methodology (IFM). While there exists overlap between the architecture discussion and the content of “Architecture in Practice” (see my review for that text), the authors quickly move forward to discussing the delivery of valued features to customers and how parallel development of multiple MMFs is often well suited for meeting customer needs. Although the chapter on how to manage intangibles provides a much more simple explanation than books such as “Making Technology Investments – ROI Road Map to Better Business Cases”, the authors get their point across in a succinct manner. Similarly, the authors discuss how IFM can thrive when used with the (Rational) Unified Process and other more agile software engineering methodologies.
Rating: 4 / 5
#4 by Alistair Cockburn on April 25, 2010 - 12:24 am
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).
Why not 5 stars if I don’t find anything wrong with it? Because 5 stars would mean to me that really everyone should run out and buy it. This book is the (correct) start of a conversation with a more limited audience — it satisfies its intended purpose extremely well.
Read this book if you are an incremental-development devotee looking for the next level of understanding; or you have to interface to a financial guy(gal); or you are one such yourself.
Rating: 4 / 5
#5 by Christopher J Matts on April 25, 2010 - 12:41 am
I read this book because Tom and Mary Poppendieck recommended it to me at XP Day 3 (Their book on Lean Software Development is a must read.). It is an important book because it places Return on Investment (ROI) at the heart of IT prioritisation and decision making. If your company is not doing this, then it will have lots of trouble with its IT projects. The book explains ROI and Net Present Value (NPV) and then presents a heuristic for delivering the optimal deliver of ROI. The heuristic depends on having groups of functionality with associated revenues (These groups are called Minimum Marketable Functions or MMFs). The book then presents a methodology for delivering optimal ROI that works with RUP or Agile. I’m tempted to try out the heuristic although I suspect that most decent project managers could work out the optimal delivery without the use of the heuristic (one of the approaches they suggest.).
The big question that the book leaves me with is “Where do the revenue figures come from?” The book gives an unsatisfactory single sentence answer along the lines that they are produced by marketing and the business.
Overall I liked the book, it is well written and easy to read. My one contention is that the RUP chapters comes before the one on Agile.
Rating: 4 / 5