In November I had the opportunity to stay a whole week with Kent Beck. it-agile GmbH invited him for two courses – Responsive Design and Advanced TDD – and one workshop to Hamburg, Germany, and I took both courses and the workshop. Today I was contacted by Johannes Link who was surprised not to find a write-up of this week on my blog. It turns out somewhere during the past year I have turned into a reporter. So, here is my summary from what I could get from my notes. Initially I planned to write it via email to Johannes, but then I though why not share those comments on my blog. Maybe others are looking forward to it.

Workshop with Kent Beck

We started the week on Monday with an internal workshop with Kent and Cynthia. Among questions like “how did you become a goat farmer?” there were also other questions which were more technical. These are the things I found interesting in my notes.

Kent explained that Java is currently on the decline. There are IDEs upcoming for languages such as Ruby or Javascript. But he noticed a social cycle in the choice of programming language. Java is currently going down just like the Roman Empire. Nowadays Java is used as a platform for other programming languages.

Regarding XP, Beck explained that he made the experience at an English Bank with XP, that “they can’t tell us what they give us until three weeks before they give it to us” is not a good business model. Instead of thinking about “I’m not telling you what I’m about to do” programming is a service, and that service should be reliable and transparent to the customer. At some point Beck explained he had realized that the early adopters of extremme programming also killed it with the “we’re not telling you what we do, it’s not your business” attitude. For the first edition of the XP explained book he wrote it very programmer centered. The second edition though shifted towards responsibility, recognizing there are lots of people affected by software who need the transparency which was lacking up to that point. Beck also explained that Scrum are the easy parts from extreme programming.

Regarding Kanban, Beck said that it provides organizational distance for the feedback cycle. This might be a strength, since changes can be brought to the organization adopting Kanban more evolutionary, but also more slowly by then. Kanban makes bottlenecks visible. He referred to Scania who use Lean manufacturing. They have a high degree of transparency. When something oges wrong, they stop-the-line for the whole production system, and fix the problem. They also replan every day, focusing on a transparent process. Software development is about people, not process. That said, any methodology – XP, Kanban, Scrum, you name it – does not make X better, it’s the people that do make the difference.

On Lean startups Beck explained that the amount of risk infects the derived style First of all for a startup we need to find a niche. The first idea to make money is probably wrong in this. So, instead of starting, and learning that lesson in a year, you should ask yourself how to find out about your flaws maybe in three months. You want to reduce the risk for your startup early on. Therefore you have to validate your assumptions early and often. During the early days of a startup you don’t want to involve any programming. You take your idea and try it out, question the idea in order to validate it. This could be to google for a competitor, this could be to put a static website up, and get the feedback from that website. Regarding Lean startups though, money is the best feedback that you can get. So, you might want to set up a store in two days with just static pages, and just a payment button. The payment button will not do anything in the first version, but you can see how many of your visitors are going to pay for your service. By tracking how often the button is clicked you get to know your potential, and you reduce the cone of uncertainty. Of course, you will fail quickly and frequently also, but you start with a low risk. He drew a circle from Build to measurements to learning. He explained that Lean startups start with the learning first, then build something, and measure in order to validate their assumptions. Based on this, they learn, and the whole cycle starts over.

Beck also explained that such a development cycle does not scale very well. Referring to his Software G Forces talk, he said that for startups there is a point where the dynamic changes. The difference lies between being on the run-way, and climbing.

Beck explained that developers should develop software as if it was their money they spent. “Would you spend your money on writing that document?” The basic difference being one of responsibility, or even accountability. On organizational culture he explained that it’s way easier to be absolutely transparent and open as to hide something. Secrets are a measure of weakness for an organization, since secrets need energy to hide and stay hidden. The XP practices and principles provide a social standpoint. Transparency is the default.

The differences between the methods lie according to Beck in the rather technical focus of XP and Scrum compared to the business focus from Lean. If you want to explain refactoring to a business person, it’s an invest to switch the behavior later to a different implementation more easily. On computing history, Beck said that in his early days computers were rather expensive compared to rather inexpensive programmers. Nowadays computers are inexpensive compared to programmers who became more expensive than a machine. In the days of internet scale programming, computing is basically free.

Beck said that Continuous Deployment leads to better technical skills. You have to think about the whole deployment cycle. Beck referred to the Volcan mindmelt as a analogy for the thing that happens during pair programming. Two minds become one. Though there might be social resistance at first, when the social decision is made to pair at programming, teams can unleash their power. Regarding Software Craftsmanship Beck explained that it has some pros and cons. On the pros the honing of skills and getting better are valuable. On the negative side, you can’t make me program badly. So, the underlying problem is rather that bad programmers don’t know about their short-comings. So, the question should rather become “Can you take your skills to create a service for others?”

Responsive Design

The following two days Kent Beck taught us his Responsive Design class. He mentioned that latency vs. throughput is a trade-off decision that he makes as a programmer. In order to drive his design, he uses four strategies. In case he can see the implementation, he can leap into it, or develop it in parallel. If the solution is invisible to him, he either uses a stepping stone, or a component, or uses a spike solution, or a simplistic approach which gets refined later.

For a leap solution which he can see, he goes safety first, working test-driven in tiny steps. For a parallel implementation he goes down with scaffolding, and up with safety. A parallel implementation is a second function which does nearly the same as the first. At some point later, the first function is thrown out then in order to improve the design of the code. If Beck can’t see the design he wants to have, he starts with a separate component. While a component might be well known to him, there is some risk of over-engineering and lack of feedback from the new component. For simplification Beck starts to think about the one thing he might build to get started. This approach is almost always possible, and it establishes initiative for him. But there are some non-linerarities in requirements order involved. One final strategy to improve a design if you can’t see how to make the change, add the feature to the codebase anyways, but always expect to pay for this later.

Beck explained the concepts of Coupling and Cohesion. Coupling is the probability that a change in one element will require a change in another. Cohesion on the other hand is the probability that a change in one sub-element will require a change in all others. While these seem to be the same, there is a tiny difference. Beck explained that good designs yield higher cohesion, but lower coupling.

On the definition of design, Beck explained that adding features should be straightforward with a good design. The designer has a social responsibility first, and a technical second, or derived from this. Software design needs therefore trust. As designer needs to be trustworthy as well as offer trust. Latency, throughput and variance influence design decisions. Software design is a social sport. One vital point for designers is to change either the interface of a class or the implementation, but never both at the same time.

Advanced TDD

During the last two days, Kent Beck taught us advanced topics for TDD. We worked through many exercises. First, we were asked to have the shortest red period while doing a kata. He showed us how flow, confidence, and risk influence our decisions. The decisions are trading off between tiny steps on one hand, and huge jumps on another. If I feel safe to take a larger step, I can do this (when not new to TDD!), but always keep the ability to re-cap in case I run into a dead end.

Kent Beck explained how to implement a unit testing framework, and what he did with JUnit. He explained Afters and Befores of the JUnit framework. At some point he got stuck with the implementation, and then dived in, and applied a practice he also uses with ugly code. He extracted a method object. By extracting the ugly, long, unmaintainable method into an own class, he insulates changes in one class. Referring back to the Responsive Design class, this is a way to work with a Component. The method object gets all the variables local to the function as fields, and has one compute() function. From this point forth he improves the code, y extracting other methods from it. The After and Before feature of JUnit lead him over the Method Object to JUnit’s rules. Timeouts, Afters, Befores are now based upon JUnit rules, rather than being implemented in the TestRunner itself. Thereby the code for the runner itself got way easier.

Finally, Beck explained JUnit’s Theories, from which I have little left. On the second day we talked about the usage of mocks. Kent Beck explained that he does not use mocks, but instead works from the lowest assumption, validates that assumption, and works to the next. He splits up the design strategy path, and avoids to mocks by this completely.

As exercises we worked through different katas, also changing the order of tests involved, realizing that we ended up with the same code design in the end. We talked about decisions which test to use first, and I think I remember that we also worked through a list of decisions we made when turning a red test to green – something similar as Robert Martin’s transformations. We played with doing large steps while TDDing our code, doing tiny steps, having the shortest red, refactoring only on the green bar, or peeling out the design while refactoring. We also made experiments with doing messy steps. The whole week was great, and I made a lot of experiences regarding my usage of TDD, and how to advance it even further.