Software by Numbers (not-wide)

[Warren Dew]

Thanks for the link to the table of contents in the other thread! Unfortunately the width of the column expanded to the size of the link, so I'm posting my follow up in a new thread....
Looking through the TOC, I can get a good idea of what the subject matter is about, but I have a couple of additional questions:
- What is the intended audience for the book? It looks to me like it might be primarily engineers; I'm wondering if it is also useful for management and/or sales.
- The process described seems to be kind of heavy weight, at least from the point of view of small projects involving say two or three engineers for less than a year - I'm guessing using it in a full blown way would be more appropriate to somewhat larger teams and projects. For the small projects, is there a stripped down version that's useful, or concepts (beyond the basics of ROI and such) that are useful? If so, how might these concepts be applied to such small projects?
(And yes, I know I have more chance of winning a free book if I post each question separately, but I guess my goal is more figuring out whether it's actually worthwhile for me to shell out money for it.)

[Valentin Crettaz]

- What is the intended audience for the book? It looks to me like it might be primarily engineers; I'm wondering if it is also useful for management and/or sales.
As mentioned in this thread, they "wrote the book specifically for developers, project managers, and CXOs who may be interested in seeing software development as a value creating activity".
- The process described seems to be kind of heavy weight, at least from the point of view of small projects involving say two or three engineers for less than a year - I'm guessing using it in a full blown way would be more appropriate to somewhat larger teams and projects. For the small projects, is there a stripped down version that's useful, or concepts (beyond the basics of ROI and such) that are useful? If so, how might these concepts be applied to such small projects?
I think that this discussion might provide some answers to your question
[ April 28, 2004: Message edited by: Valentin Crettaz ]

[Jane Cleland-Huang]

We really see IFM as something that can be applied either more or less formally. In fact our book dedicates two chapters to explain first how to apply IFM within a RUP setting, and then secondly how to apply it within an XP setting.
In addition to that there are some useful 'pieces' of IFM that can provide information into a lighter agile process.
As an example you could take certain IFM concepts and use them to figure out whether it would make sense to develop version 1 or version 2 of an architecture. Say for example that you wanted to develop two MMFs - A and B. Architecture Element 1 (AE1) would support MMF A but not MMF B. AE 2 would support both of them, but would cost a little more to build.
The "traditional" approach says plan for the future - build AE2, and plan on MMF A and MMF B. THe agile approach says build AE1 and MMF A, and then refactor AE1 to AE2 when you are ready to build MMF B. (I realize there are a few assumptions in this example - but I hope you get the picture).
IFM techniques can be used to put some numbers to this question. Given the likelihood of building MMF B (ie its probability), we can calculate the actual costs and returns to the project if we take each of these options. Which one makes financial sense? Its a small calculation - but provides financial insight into what would otherwise be a principled decision.
When we 'played around' with these numbers we often found support for the refactoring approach. However - the numbers show on a case by case basis which approach makes sense. Again this gets to the core concepts of IFM - which is to provide a "financially informed approach to software development".

[Warren Dew]

Originally posted by Valentin Crettaz:
As mentioned in this thread, they "wrote the book specifically for developers, project managers, and CXOs who may be interested in seeing software development as a value creating activity".

Yes, I'd read that. I was hoping for a more specific answer; I don't see developers and CEO/CFO/CTO/COOs as being very similar audiences.
Perhaps I need to rephrase the question: Jane, would you or the other authors see a CEO of a small company or the CTO of a small IT department using this book, given that he didn't have the resources to get the detailed calculations done?
The version 1 versus version 2 example is a good example, by the way, thanks. Can you tell me whether that's an example from the book, or just an illustrative example you came up with to show how the book might be used? Are there a lot of that kind of example in the book?
Also, how does the method handle the issues of risks of failure and risks of overruns, given that these can be hard to acknowledge and estimate?

[Jane Cleland-Huang]

We do include lots of examples in the book. In some cases to explain a concept we just use generic terms such as MMF A, MMF B etc, but then we also have a fairly extensive set of real examples. In fact we use a series of short examples throughout the book to illustrate IFM, and then the final chapter provides a beginning to end case study of applying IFM in a banking portal application.
As you point out, our audience is broad and covers developers, customers, CXOs etc. However this reflects the fact for an organization to successfully manage software development as a value creation activity it requires buy-in from all of these stakeholders.
As far as CXOs are concerned - our experience so far is that their response to IFM is very positive. As I mentioned in the Managers thread, one of my students gave a copy of the book to a CEO in this company. The CEO's response was, "this is how I want our company to develop software in the future". He then bought copies for all of his project managers so that they could apply IFM principles on future projects. So far we have only had positive responses from CXO's who have read Software by Numbers.
Although CEOs may not necessarily understand some of the technical aspects of the book to the same level as the developers, they certainly seem to get the intended message - that IFM is a new way of going about the business of software development.