ACCU 2007 Day 2

Towards Simple Code: A Workshop on the Value of Simplicity in Software
Giovanni Asproni, Kevlin Henney, and Peter Sommerlad

This workshop was oriented around "The Laws of Simplicity" by John Maeda. The three workshop coordinators shared responsibility for explaining the laws of simplicity and the keys of simplicity as well. To learn about the laws, check the Laws of Simplicity web site. We then broke into teams charged to brainstorm up our guidelines for simplicity. The team I participated in wrote a number, but culled the group down to three key points:

1. We believe that minimizing information lifetime is a Good Thing(tm).
2. We believe that restrictive coding standards are counter-productive because they remove options before you even consider them.
3. We believe that Design By Contract improves code quality by making assumptions explicit.
   

The second point received the most questions. I explained the belief by asking people to reflect back on times they have had to reformat a method or module to make it readable. Thinking hard about that moment, was that necessary to do because of the code format or because of the lack of logical structure to the code itself? As the people in the room, we developers, when reflecting honestly, have to admit that we almost never reorganize code because of its format, but because of its poor logical organization.

It is interesting to note that few of the other teams applied simplicity to their own presentations, leading to quite long lists with relatively little explanation. This workshop was excellent and is one of the elements I want to share with the folks back at work. To see the results of our work see ResultGroupG.

Introduction to Component-Level Testing
John Lakos

This two-part session is nearly impossible to summarize, but suffice it to say that this three hour experience made the entire trip worthwhile. The core idea of the talk was that the physical organization of the files composing your project(s) is just as important as the logical organization of the classes. This idea is often and easily overlooked by developers, especially more senior developers. In large projects the physical organization of the projects often takes a back seat to the logical organization, if it is even considered at all. I am happy to report, that at DeLorme, we woke up to this reality some years ago and have been organizing our projects according to their dependencies for some time. Our hierarchy could probably use some expansion, but confirmation of our decisions certainly felt good.

As a side note, within five minutes John mentioned Barbara Liskov's Substitutability Paper and the Open-Closed Principle within five minutes of each other. This before the computer science session tomorrow. This is for you Mike!

Another wonderful point he made was about the cost of test driven development. He theorized two teams, both were given the same problem. The first team got right to the work and finished in two weeks and entered QA for an unknown time. The second team started writing tests, then the backing code. After two weeks they were 50% done. Which team is further ahead? Does it even matter? You know the second team has two weeks of work remaining, whereas the first team has an engagement with QA which will last an unknown amount of time.

He moved from design to testing at this point with an exhaustingly brilliant survey of component-level testing techniques. His first example was along the lines of "bool isOne(int value)" and his second example was Jeff Howe's famous countBits() function. Depending on the algorithm used, and he showed several, the testing requirements can be quite different. The largest complexity test results from the lookup table implementation for that function.

This is another talk which I want to share with people at work and it left me positively dizzy with information overload. John was a brilliant, skillful presenter who packed at least a week of information into a mere three hours. I imagine it will be several days before I fully appreciate everything he set out for us. This huge presentation again made the entire trip worthwhile.

Grumpy Old Programmers

Steve convinced me to attend this panel discussion with promises of hilarity. It was alright, but somewhat less uproarious than its reputation.