ACCU 2007 Day 1

The Pendulum of Software Development
Mary Poppendeick

The keynote was delivered by one of the two presenters from the pre-conference session I had attended yesterday. She covered a history of software development, primarily her own background, from 1960 to 2000. Then moved on to a few slides repeating her themes from yesterday: Stop-the-Line-Quality, etc.

Coaching Software Teams
Michael Feathers

This presentation was amazingly good, and Michael has a quiet an unassuming manner which imparts power to his points. A key initial point which formed a foundation for the talk was that you cannot expect everyone on a team to share the same level of commitment. Essentially, while you can help people rise to a new technical threshold, changing their commitment level is difficult and probably not worthwhile. They key question he asked us is, "Would you do your job if you were independently wealthy?" I certainly would and so indicated, but there were a very few people in agreement.

Another approach he uses for working with teams is to imagine the entire team as a single person or "Pat". He then works to understand Pat's personality and emotional state, which is essentially the personality and emotional state of the team as a whole.

The discussion then moved on to how to actually coach a team. He was careful to note that nearly all coaching should be done with individual teams rather than to the team as a whole. The most teachable moments, in his experience, are when the tension, similar to but not always stress, is high. The reception of the lesson taught resolves the problem and disipates, or releases, the tension. This tension/release cycle was another frequent key phrase during the rest of the presentation.

He then spent a fair amount of time reviewing about fifteen or twenty specific coaching techniques. There were several very interesting ones, including a somewhat strange idea called "The Flounce." He told a story about a team which had worked hard to improve their process and quality, yet management continued to feel as though it was not enough. The team felt terrible about the problem, but no one would openly admit it. Another coaching consultant came in to help the team and noticed immediately what was wrong. Rather than just come out and say it, he brought the team together and said there was a huge problem, then did not name it. As people made suggestions he kept saying, "No. That's not it." increasing the tension within the team. Finally, someone came out and described the problem with management's expectations and the team released and worked to resolve the problem.

Finally, the discussion moved on to thorny issues in coaching: ethics, personality conflicts, and cliques. Anyone who has coached a team has run into these issues at one time or another and his suggestions were both concrete and useful. One of the more interesting titles he mentioned in the presentation is "Teamwork is an Individual Skill" by Christopher J. Avery. I have put in a request for this text.

Fingers in the Air - A Gentle Introduction to Software Estimation
Giovanni Asproni

This presentation was quite interesting and reviewed many things I already knew about software cost estimation. There is clearly no new "silver bullet." I did find his suggestion that you use multiple methods if at all possible. He said: count, measure, then judge. This meant we should first attempt to estimate by counting something (KLOC, function points, etc), failing that by measuring something (story points, complexity), and as a last resort by expert judgment. If making an estimate by this last process obtain two or more different estimates.

I realized that I had often heard elements of this presentation in talks by another Software Architect at DeLorme. Welcome to the "Cone of Uncertainty."

Linting Software Architectures
Bernhard Merkle

This presentation is almost impossible to really evaluate. As a baseline all of the presentations are one hour and thirty minutes. That is quite a lot of time, but with an interactive audience can burn away pretty fast. Bernhard's presentation was about sixty minutes of general discussion about exploring architectural defects. The material was simply too basic for Steve and I, but we hesitated to say anything for fear there were less experienced folks in the audience.

One core technique he used for architectural linting of existing systems was to create a representation of the expected architecture. Then reverse engineer the architecture from the code and compare the two descriptions. This allows you to detect differences between your expected architecture and what was actually implemented.

After burning up two thirds of the session with little or no interruption due to questions, he started to describe some tools. These descriptions used screen captures from running the various tools on publicly available Java systems: JDK, Ant, Eclipse, etc. This information was genuinely valuable, but felt as though it came too late.

Suddenly, with but one minute to go in the presentation interval, he broke out actual live copies of each of the tools. The disappointment was almost palpable. Everyone in the room would have loved to see the tools themselves an hour ago, rather than during the last sixty seconds of the presentation. In the end, the presentation was enormously useful, but just not all that well organized.