ACCU 2007 Day 0

Steve and I signed up for the full day pre-conference tutorials at the ACCU 2007 Conference. Steve signed up for "C++ Productivity" by Hubert Matthews, which he enjoyed very much. One challenge from the session was to write a complex calculator program in C++ as fast as possible. Steve leveraged his experience with SPIRIT and whipped one off in short term. You can see why we all think so much of his work. Brilliant, as they say here.

I attended "Lean Software Development" by Tom and Mary Poppendieck. The presentation discussed techniques for applying the principles of the Toyota Manufacturing System approach to software development. Many of the essential concepts were familiar to me from my use of Neils Malatoux's Evo Methodology. 'Lean' also makes use of timeboxes, frequent releases, and early testing. One of the key points made during Mary's section of the presentation was to stop maximizing local productivity and start maximizing system productivity. Essentially, rather than having each developer at maximum capacity, developing both immediately useful and prospective (not immediately useful) features, look at why it takes so long to get a particular feature from the concept stage to the release stage.

She was also very, very firm that feature requests from customers and sales should be processed immediately and turned into code as soon as possible. I asked a number of questions about this issue, but never gained what I considered a satisfactory answer. There was a frequent recourse to the traditional new systems attitude: "if you do it, you will see". While I see many of the related points, I wonder if the approach is so oriented around web projects and internal IT projects that there are limits to the application of it to large scale commercial software. For example, she was quite strident that requests from customers should be filtered, accepted or rejected, and then worked on as quickly as possible. For a small scale or internal project, I imagine this would work pretty well. For a very large customer base with a huge volume of input from many sources, this is both impossible and not particularly desirable. There were also discussions in the tutorial that this approach may not dovetail with the sales cycle and other business processes.

There were several really key items which I found a lot of value in. The distinction of products and projects and team organization was very interesting to me. I am used to the project-style of organization, which is a frequent style for smaller companies with multiple products. Mary made some excellent arguments about the value of product rather than project orientation. I am interested in exploring some of these ideas at work.

Tom took over with a discussion of software quality. I agreed often and significantly with much of what he had to say about unit tests, acceptance tests, and so forth. Having successfully tried test-driven development, it really works for new projects. It is difficult to use in the context of a large, legacy code base and it also is difficult to keep doing it without a team organized around that principle. One project we worked on wound up with more tests than code. It has been a big help to the quality of the project. Tom suggested we look into the "fit framework" for automating acceptance testing.

While I am not sure I would attend their track again, I certainly learned a few things.