Two weeks ago, I was at the JavaZone conference (in Norway) for the first time. There, I facilitated a Vaadin 7 workshop and presented an Introduction to Mutation Testing. Moreover, I attended many great talks by brilliant speakers, but one was really head and shoulders above the lot: “Software Design, Why, When and How” by Kent Beck.
For those of you that don’t know about Mr Beck: he’s the co-author of the JUnit testing framework, he created Extreme Programming, he is at the origin of Test-Driven Development methodologies and much much more… This is just to say that I was expecting much from the talk, especially since Software Design is at the root of most of my work though I’ve been disappointed by so-called “star” speakers in he past.
The first thing to note is that the talk took place in an unusual room, as the stage was set between two opposite sets where half the audience was located. In essence, you could speak only in front of half the people at any one time. Not an easy feat! Also, I was very surprised by Mr Beck not using any slides in his talk. Of course, he probably had some piece of paper somewhere but the magic is that his talk was very fluid. Given the amount of time it takes me to prepare my talks with slides, I can only wonder at the time it took him to prepare without. In the end, the result was impressive!
The content of the talk, however, was all about a single and very simple message: Software Design is all about context. Sometimes, you need to design upfront, sometimes, it will cost more. Sometimes, it’s better to refactor, sometimes, not. Sometimes, one should refactor now, sometimes later. And so on. In essence, the meme about code duplication being bad is just that, a meme. This is despite the fact that Software Designers need to care about efficiency first and about how to best use scarce resources, i.e. time.
The last part of the talk was devoted to three main qualities of a Software Designer:
- Tolerance to ambiguity
- Ability to postpone decisions
- Social skills [sic]
This talk really stroke a chord in me as my studies were not in Computer Sciences but in Architecture (as in buildings). At this time, I was very pissed off that Architecture was not a real science, that there was no right or wrong answer and that you were never completely sure to have an adequate solution until the thing is finally built. This uncertainty was really a burden at that time, and I went to software development because either my code compiled – or not, and my application produced the expected output – or not. But with Software Design, that’s exactly as in Architecture (as in buildings, remember?), it’s all about context and gut feeling and experience.
All in all, this was really a great show. Even better, I went to him after the talk to tell him about the Architecture stuff and his conclusion is the following:
This just exactly match my experience, as I’ve made plenty of bad decisions in my career, so I guess I’ve plenty of material to take good decisions from in the future
And as for those who want to enjoy the integrality of the talk, here it is in all its glory. Thank you Mr Beck.