techblog 

This is the third instalment of my experiences at JAOO 2007, following on from my previous description of day two.

Once again, here are some quotes from the sessions I attended so that you can get a flavour of the day without having to read all of my notes:

• Kevlin Henney - With Economy and Elegance - “Our job is to turn a general purpose machine into a specific one”
• Laurent Bossavit - The Journeyman’s Tale - “You are a 17th Century Cathedral Builder!”
• Michael Feathers - The Ethics of Error Prevention - “Quality is in the intangibles”
• Pete McBreen - Applying Craftsmanship - “Software should be a pleasure to use, or we’re doing it wrong”
• Closing Panel hosted by Martin Fowler - “Iterative development is a constant cycle of failure”

Kevlin Henney - With Economy and Elegance

In this session, Kevlin talked about metaphors for software development and about beauty in code. As he said, “Our job is to turn a general purpose machine into a specific one”. That means that you should be concentrating on solving the job at hand, not solving general problems. If you want a system to solve general problems, take an operating system and compiler and away you go…

He talked about the idea of software engineering and his belief that criticisms of software development as not being true engineering stem from a misunderstanding of what engineering is. He gave a nice quote from the Institution of Structural Engineers:

Structural engineering is the science and art of designing and making, with economy and elegance, buildings, bridges, frameworks and other similar structures so that they can safely resist the forces to which they may be subjected.

and translated it to software:

Structural Software engineering is the science and art of designing and making, with economy and elegance, buildings applications, bridges, frameworks and other similar structures so that they can safely resist the forces idiots to which they may be subjected.

Having made this joke, he pointed out that metaphors are used a lot, but they always break down at some point. So software development has been compared with Civil Engineering, Mathematics and Gardening. In the case of Civil Engineering, the call has always been “Make software like building bridges!”. He pointed out that until fairly recently, bridges had a habit of falling down. This caused engineers to move towards more professionalism.

The big problem with this is that civil engineering is physical engineering and software engineering is information engineering. So the two disciplines are cousins rather than siblings. There is also an assumption that all engineering must be plan driven. In fact, disciplines like chemical process engineering are not plan driven. So trying to make software engineering into a true engineering discipline does not mean imposition of rigid plans.

He then moved onto looking at the ideas of economy and elegance. He pointed out that clean code attracts care. This reminded me of the pragmatic programmers’ idea about Fixing Broken Windows. Also, much of the complexity in code is accidental complexity in that it doesn’t exist in the problem domain. We added it ourselves.

Kevlin also mentioned the idea of “Decremental Development” which is the idea that you need to remove duplication and continually simplify to shrink the size of the codebase. He pointed out that the smaller and simpler the code is, the easier it is for us to get our heads around it, which eases maintenance.

Laurent Bossavit - The Journeyman’s Tale

This presentation was the one which made me think the most about what I have seen and learnt here in Århus. Not because of the content per se (sorry Laurent!), but because of the reaction of the audience to it. He started out with a list like this:

• You use complex skills that your customer doesn’t want to know about.
• You did most of the learning on-the-job rather than formally.
• Your work underpins much of what goes on in your society.
• There is pressure on you to lower wages and to deliver faster.

He asked people to raise their hands if they agreed that it applied to them, which most of them did. He then said “You are a 17th Century cathedral builder!”.

He then went on to talk about French craftsman’s guilds, or “compagnonnages” and how this concept could be applied to software development in the 21st century.

What was very surprising to me was that lots of people started walking out. Then at the end one of the questioners was quite hostile and accused him of suggesting that a university education in computer science was worthless.

Now the talk was a little too focussed on historical details, but it did have some interesting ideas. So I was a little puzzled by the reaction. I wondered if this was a case of what Glenn Vanderburg said yesterday “new great powerful things won’t always look like what we already understand”. Or if perhaps as suggested by this post, that the audience didn’t think it applied in Denmark. Anyway, the only time I have walked out of a talk of this kind was when I found the delivery to be so irritating that it set my teeth on edge.

Michael Feathers - The Ethics of Error Prevention

He opened this talk by showing a pageful of code and asking “where’s the bug?”. This was to make the point that code is pretty opaque and bugs are not obvious. He then talked about the very low bug count seen by the code used to control the Space Shuttle, of the order of 1 a year in a very large code base. The way they achieved this was via a very rigid process with multiple levels of review. The downside is that this environment completely stifled any innovation.

It is well established that higher level languages have a lower bug count per feature, so he asked if it was ethical to still be using C? He also had an interesting anecdote about moving from C to Pascal. Since he had started in an environment where running off the end of an array could be serious, he applied a similar level of diligence to Pascal. So he was amazed after using Pascal for 6 months to see another programmer with an “array out of bounds” error. He’d never seen it before. So wondered if error checking just serves to make us slapdash. He compared this to the Shared Space traffic management techniques where pedestrian protections are removed to force drivers to pay attention.

The presentation then moved on to discuss various other techniques that have been used to avoid programming errors: Design by Contract, Clean Room, Test Driven Development, Fagan Inspections and Hindley-Milner typing. Each of these has been shown to help, but in each case the benefit seems to come from contemplating your code more, or from a different perspective. Michael Feathers was of the opinion that we need these ‘tricks’ to keep us on track.

He finished off by saying that in coding “Quality is in the intangibles” and that the space between the coder and the code is where the most important things happen.

Pete McBreen - Applying Craftmanship

I have to admit that I found his presentation style was slightly irritating, but Pete McBreen did have some interesting things to say. He said that we need to deliver applications that are a joy to use. His take on this was that the idea of “Software Engineering” has had 40 years to deliver its promise and has failed. So we need to concentrate on Craftmanship instead, because development is a high skill task and you need to transition from apprentice to master just like someone in a traditional craft.

He said that university doesn’t effectively train developers and that when they start work, they should work as apprentices. They would contribute to real projects, but would work in the area of maintenance. This would mean that they would get used to delivering work quickly and the feedback would be rapid too. He also wanted to emphasise that maintenance should not be a second rate area. We should not be writing new systems unless absolutely needed, as putting improvements into existing systems gives a much better and much quicker return on the time invested. He was also dismissive of the idea of separate teams for development and maintenance.

Continuing the theme, he said that software development has workers and managers, but no foremen. I’m not sure quite what he meant by this. Wouldn’t a technical lead or agile coach fill this kind of role?

Going back to talking about systems being a joy to use, he told a story about making his developers go and use the system they were maintaining. They worked for a few weeks on it and came back saying “Right, we know what needs fixing!”, but he made them go back and keep working on it. They came back after another week or so and said “Right. We really know what needs fixing in this system”, but he sent them back. Only when they threatened to resign if they weren’t allowed to fix the problems did he let them. A funny story, but I’m not sure it is a best practice management technique!

Final Panel - Martin Fowler (host)

The final panel consisted of 3 Erik/Erics: Erik Meijer, Eric Evans and Erik Doernenburg, plus Diana Larsen. Martin Fowler was the host. They each talked about something they had got from the conference and this was then discussed by the other panellists, plus contributions from the audience.

I didn’t write down everything that was said, but one strand of the discussion interested me in particular. Eric Evans said that he had enjoyed the session given be Rebecca Wirfs-Brock on architectural reviews as analysing an architecture is a hard thing to do. Erik Meijer said that he spends much of his time in Microsoft trying to stop people creating dependency injected factory factories when all you need is to call new to make an object. There was general agreement that simplifying a system was a good thing. Martin Fowler then said that when everyone agrees on something that he gets worried that the real question is being glossed over. Can we actually agree what simplicity is?

Eric Evans then said that when you are designing the architecture of a system you should work from 3 or 4 motivating concrete scenarios that it should support. You choose these to be fairly well spread over the problem space. You then judge if you have overcomplicated things if there are parts that can be removed but still support those original scenarios. Over time you then ‘challenge’ the architecture with further scenarios and adapt the architecture over time.

Erik Doernenberg said that a clean architecture was often a beautiful or elegant one and that symmetry in code was generally a good thing. So if you have an object called a Reader, its counterpart object should be a Writer, not an Exporter. He pointed out that in the arts symmetry is not always considered a good thing as it is too ‘obvious’.

Someone in the audience asked a question about learning from failure. Does this mean you should aim to fail? Martin Fowler then said that you need to accept that you will make small mistakes. You don’t want to avoid failure, but you obviously don’t go seeking it out. You aim to be able to detect and recover from failure instead. He said that iterative development is a constant cycle of failure. In a good way of course!

Finally Eric Evans said that he thought the theme of the conference had been the balancing of iterative processes with architectural values.