Developers prefer to talk in terms of value generation without developing related revenue projections. Business stakeholders usually don’t realize that delivery sequences and architectural options have a significant impact on project level ROI. Clearly, software development requires a more financially responsible approach […]. This situation clearly calls for a close collaboration between developers and business stakeholders.

The previous paragraph pretty much sums up the basic idea of Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. Iterative delivery and fast roll-out to production makes perfect sense and I do not think that anyone can doubt that, but can you actually put a value on it? Can you compare two alternative delivery plans for the same project? Denne and Cleland-Huang set to do exactly that. By developing a financial model to evaluate and compare delivery plans, the authors show how to make an informed decision about prioritisation on a project so that it maximises the desired financial effect, either reducing risk, optimising cash-flow or return on investment.

Denne and Cleland-Huang explain how to identify and evaluate the financial impact of Minimum Marketable Features, including “intanglibles” such as brand value or customer retention. Then they develop a system of heuristics that combines this information with technical and architectural constraints, prerequisites and timing constraints to come up with the best possible delivery plan, depending on what you want to achieve. Through several case studies, they show how just choosing the next most important thing isn’t as nearly as effective as considering the financial impact of the entire delivery plan. Somewhere in the middle, they also come up with a way to estimate the financial impact of the project by forces other than black magic which helps us answer a key question: should we do this at all or should we do something else?

Effect Managing It, by Mijo Balic and Ingrid Ottersten, deals with things that happen even earlier in the process – coming up with a list of features to achieve the desired business effect. Instead of focusing on functionality, Balic and Ottersten look at software projects as agents of business transformation. The authors argue that the ultimate goal of software projects is to achieve a business change, and that one of the key reasons for failure of so many projects is that the focus is often on the wrong things. They explain a model of structuring requirements analysis in a way that ensures achieving the desired business effect. That focus on business impact, not functionality or technology, is what they call “Effect Managing”.

Effect Managing shares many key ideas with behaviour-driven development and agile acceptance testing, but deals with things that are much earlier in the development cycle. Balic and Ottersten base their model on first considering who can deliver the desired change (stakeholders in the BDD lingo), then thinking about how these people can deliver it and what the software needs to do to support that that. Organising all these ideas in a hierarchy which they call an “Effect Map”, this model provides visibility similar to the Goals-Features-Requirements model, but in my opinion much more effective because it is visual. After trying out effect maps on two projects, I’m astonished how they open up a discussion and provide structure to the process of selecting the features for a project and probably equally important throwing away features that are less important.

Be warned, though, that both books are relatively hard to read. Although they are short, less than 200 pages each, the flow of ideas in both books is a bit hard to follow. Effect Managing IT at times reads like a literal translation (from what I understand, the original book was written in Swedish) and Software by Numbers is full of financial tables and formulas. Nevertheless, I think that both books have such great value that getting through them is well worth it.

Given the authors’ backgrounds, it’s not surprising that this book has a lot to say about using mock object libraries. Mock objects are arguably the most misunderstood and misused concept in software development today, so this book should be a valuable resource for most software development teams. In the part dealing with mock objects you will find strategies for using them successfully for software design, guidelines what to mock and what not to mock and lots of examples how all that looks in code.

The book isn’t written in the usual imperative way (“you should use this because of…”) but reads much more as an experience report (“we use this because of”). This might be unusual at first but I really like it, as it puts the things into a much more different perspective. Many of the topics addressed by this book are quite controversial and the authors have wisely chosen the voice to avoid any notion of preaching. I found myself disagreeing with parts, especially around bundling acceptance and end-to-end testing together. However, as the material doesn’t preach but tell what the authors are thinking about, this did not bother me at all.

All in all, an excellent book. Grab a copy from Amazon now.

Here are some related links:

• notes from Steve Freeman’s presentation on mock objects at CITCON Europe 09
• book web site
• Steve Freeman’s blog
• Nat Pryce’s blog

The main theme of this book is fitting testing tasks into agile projects, and as such this book really is long overdue. Most agile books are written by programmers for programmers, leaving testers in particular to fend for themselves. No wonder why so many of them feel lost in this world. This book definitely delivers on the promise to ease the transition for testers and QA engineers who suddenly found themselves on an agile project. It has a testing focus and presents things in a way that testers, coming from more traditional process oriented software projects, should understand. The key pillars of practice on which the content of this book stands are improved communication, the whole team approach, agile testing quadrants and automation, so the book efficiently points traditional testers to new knowledge and ideas that they need to focus on to contribute to an agile project. It also provides a solid framework for executing traditional testing tasks in an agile environment without lagging behind the development and causing the project to fall into the “mini-waterfall” trap.

I would also recommend it to project managers and team leaders as they will be able to see the project from the testers’ eyes and complement their knowledge about quality on agile projects. As such, it is especially an important reading for teams that consider JUnit the extent of their “testing” process. The book raises valid concerns about commonly overlooked tasks such as test planning, security, performance and usability testing, documentation testing and provides some very practical advice how to plan and execute exploratory testing efficiently.

The book is around 500 pages long, which is twice the threshold for the books I typically like to read, so it is quite heavy and not easy to carry around and read while you are on your way to work – which is a real shame. Nevertheless, it reads very easily and justifies the thickness with lots of interesting content throughout the book, staying away from any abstract academic discussions. The book is filled with practical advice and experience reports from real world projects and stories from various teams, which I found particularly interesting. For me, the key take-away is probably chapter 12, which provides a testers view at a realistic project from start to end, including tools and strategies used from the requirements to the delivery. It was really interesting to read a different take on the subjects that I often write about, especially the specification workshops (the authors call them “power of three”).

Pick up the book now from Amazon.com

The subtitle of the book probably describes the content a lot better: “building smart web 2.0 applications”. This book gives an overview of the algorithms that power many of the most popular web 2.0 sites today, providing features such as search engine page ranking, recommending products, spam prevention, match-making, identifying related topics and collaborative filtering. Solutions for those problems involve crunching huge data sets and utilising smart and elegant algorithms. As someone coming from a Math background, I really enjoyed reading a book about smart algorithms for a change. If you like that sort of stuff, this book has plenty to offer: clustering, genetic algorithms, non-deterministic optimisation, Bayesian filtering, support-vector machines and even programs that automatically create other programs to facilitate learning in games AI. If you are not a Math geek, don’t worry. This book is written from a developer perspective and all advanced Math used in the algorithms is explained in enough detail for an average programmer to be able to follow.

All the examples in this book are written in Python. I am an occasional Python user, so an additional bonus for me was learning about several open-source Python extensions that Toby used to complete the tasks, including stuff for graph plotting, xml parsing and matrix operations. I guess that knowing Python is a prerequisite to read the book effectively, but understanding just the basics should be good enough as the focus is more on the algorithms and how to apply them effectively than on actual code.

The book has about 350 pages from cover to cover so it is fairly easy to read on a bus or train. I strongly recommend it to Math geeks and data crunchers, but it should also appeal to the broader programming community, especially with its focus on forces behind popular web 2.0 sites.

Here are the details if you want to grab a copy:

ISBN: 978-0-596-52932-1
Publisher: O’Reilly
Author: Toby Segaran
Full title: Programming Collective Intelligence: Building Smart Web 2.0 Applications
Listing on Amazon.com

The central theme of this book is how the IT industry resembles an asylum taken over by inmates – with software products completely missing the goals of their customers due to a combination of programmer psychology and sales-driven feature explosion. Alan Cooper argues that programmers drive the development process using their own image as a guideline, and overloading the software with features which require expert knowledge. On the other hand, sales and marketing push for features that can be used by beginners in order to expand the customer base. Most of the software users are, according to Cooper, ‘perpetual intermediaries’, so their needs are not addressed at all. Cooper advocates fighting back against this unnecessary complexity and refusing to give in to the mass craziness. His proposed solution is interaction design, a relatively new design practice focused on improving the way users access software.

I found the first part of this book especially interesting, as Cooper prepares the arguments for interaction design by taking a look at programmer psychology, and trying to explain the root causes of miscommunication between programmers and clients (and managers in between). Illustrated with anecdotes on the edge of irony and humour, Cooper describes several “programmer�? personal traits like considering failures a success if they learned anything in the process, sacrificing everything for knowledge, insisting on hard reality and over-emphasising edge cases. Based on that, he then argues that programmers are consistently running the development show, regardless of the organisation structure or methodology, as they can, in Cooper’s eyes, always push features dull, unimportant or uninteresting features to the bottom of the list just by estimating the development time too high. Cooper also attacks programmers for developing the software with the primary aim to maintain it easily, not to meet the goals of customers, and for requiring users to gain internal knowledge of the systems they build.

In the first part, Cooper also attacks overloading products with features, and the world’s acceptance of ugly interfaces and buggy software just because it enables solving complex problems. He compares those imperfect products to a dancing bear – it looks really ugly when a bear dances, but it’s fascinating enough so that people don’t mind that it’s not really a dance.

Cooper proposes design as a key factor to product success and customer loyalty, especially interaction design. Without going into too much detail, he attributes the fall of Novel and Borland to the lack of interaction design in their products, and argues that good design is responsible for customer loyalty which kept Apple from completely vanishing, and helped them resurrect a few years ago.

His approach is completely opposite to the current trends in the software industry, as he argues for much more up-front design and against being directly customer driven. Cooper calls doing layout design after development ‘painting the corpse’, and proposes a phase of interaction design before software design. His goal-driven design technique starts by identifying core user groups and representing them by a single, imaginary person, then focusing on those person’s goals. The idea of interaction design is making that one customer ecstatic about the product, and the book contains several detailed case studies which show how to do that, but still not push away other customer groups. Once those target customers and their goals are identified, Cooper argues that having ‘named persons’ to represent users significantly improves communication, and makes it easy to remove the features which are not needed and would just introduce unnecessary complexity.

Last thirty or so pages, where the author tries to sell his process, were not very convincing to me. Out of respect for his experience in the industry I will not say that he is plainly wrong, but in my humble opinion he misses to consider some very important realities of software development. For example, Cooper compares software development with film making, arguing that the two are essentially the same in terms of having a pre-production, production and post-production phases, and that changes such as deciding to blow up a train instead of an air plane cannot be made easily in production, but can be quite easily made in pre-production. Software business and films may seem close on a silver screen, or to a consultant that just jumps from one project to another, but software is developed, maintained and supported for years after the release, which cannot map to anything in the movie world. I imagine that studio executives would just laugh at an offer to sell a popular blockbuster movie to a large retailer only if Julia Roberts was replaced by Pamela Anderson, but 15cm taller, and if the story takes place in a futuristic instead of a medieval environment. But I see changes like that in enterprise software every day – and being able to accommodate such silly requests is one of the key market advantages of good enterprise software. Again, I might just be one of the followers of the ‘dancing bear’, and trying to find an excuse for the imperfections rather than solving them – but I’ll leave that to you to decide.

I still recommend this book very much to any open-minded developer (and especially development managers). It is full of good case studies and, although I do not agree with a lot of ideas described in the book, it was very refreshing to read. Not very often did I come across such a detailed analysis of the software world from outside, by someone who has been an insider and with a viewpoint that will certainly make you think about ways to improve. I do not believe that interaction design is a silver bullet that can solve all the issues in software development, but I believe that Cooper identified real problems which should be addressed. I agree very much with him that we should put more effort into removing the complexity, and attacking unfounded common beliefs. And even if you don’t agree with the arguments which conflict with modern software development trends, there are a lot of ideas from this book that can be applied to improve software development and communication. For example, although Cooper’s approach completely at odds with Agile methodologies, his persona-focus is very similar to what Mike Cohn proposes in User Stories Applied, one of the agile bibles. Similar, focusing on customer’s goals is an excellent guideline for software development (I wrote earlier about my experiences with goal-driven development in The Magic of Goals: Focused Projects and Better Requirements and How to develop software like commanding a tank).

See also:

• The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition) on Amazon.Com
• www.cooper.com, book author’s web site.