There were just four of us at the Lamb and Flag to discuss Tom Gilb’s book Principles of Software Engineering Management. Steven and I were joined by John and Ursula. John said that he had read the book in question some years ago. He said that lots of people didn’t really get it when it came out and he included himself in that category. One of the themes of the book is the idea of inspections, but John suggested that Tom Gilb had been frustrated that no-one really picked up on that. So he ended up writing another book Software Inspection to try to hammer the point home. Apparently people still didn’t really get it. John said he realised this when he read James Womack’s book Lean Thinking where there was a discussion of how western companies could never truly understand the ideas of Lean. I admitted that I didn’t feel that I’d really got what Gilb was driving at with inspections.

Something I did like about the book was the discussion of what requirements are and how they differ from solutions. No-one else discusses this – in other development methods it is always assumed that the customer takes care of that part and has at least some idea of what they want. Chapter 4 of the book did a very good job of exploring what parts of ‘requirements’ are actually just solutions. I loved the story of the California teacher system. The customer specified that they wanted a computerised system and that’s just what they got. Unfortunately it cost 7 times as much to use the new system as the old paper-based one. What they really wanted was a cheaper and more efficient system. But they expressed this by giving a solution, not the actual requirement. As Steven pointed out, this mindset is much like the thinking in agile and lean methods, where you focus on the end goals and delivery of value at all times.

While the mindset concentrating on the delivery of value was very much like lean, I found the idea of have one hundred attributes to measure the success of a project rather different. It seemed to me that this was almost like not concentrating on your base goal. Would the project be a success if all those attributes went in the right direction but the company became less profitable and less popular with its customers?

Going back to inspection, I said that the very use of that word is almost an anathema to those who practice lean. The mantra is that you should try to ensure that there are no defects, not look for them later. Ursula thought I had the wrong end of the stick and that there would always be defects in a software product and that Gilb’s inspection is more like the lean idea of “Stopping the Line” when there is a problem.

Steven said that he thought the key message of the book was that evolutionary delivery is key to success. John agreed that you need to give the users something as early as possible. This idea is now widely accepted, even if other parts of this book are not.

Ursula talked about the idea of constantly recording task estimates as a way of improving the quality of them. She also talked about confidence measuring. This was a way to see if people on the team had doubts which they didn’t want to bring up. It would be easier for them to say they were not confident about hitting a deadline perhaps than bring up the reasons why. I said that I thought that the idea of project velocity was a good one as you don’t need to keep re-estimating all the time.

Finally, I asked if anyone understood what Tom Gilb meant by an Open-ended Architecture. Steven suggested that it meant that the design was not constrained unnecessarily. I’m afraid this is something else that I didn’t really get. Someone may have tried to explain it to me, but I’m afraid it was too late in the evening for my brain to take it in by this stage.