Gojko Adzic

I am getting more convinced every day that communication is, in fact, what makes or breaks software projects. Programming tools, practices and methods are definitely important, but if the communication fails then the rest is just painting the corpse. From that point of view, getting the language right is one of the key steps for any software project, because the language provides the foundations for all communication. The right language does not, of course, guarantee that the correct thing will be built on time and within budget — but the wrong language is practically a guarantee that the project will fail. Continue Reading »

In November, I attended a workshop on improving the understanding between customers and software development teams. The attendees were split into seven or eight groups, and there was an exercise at the end asking the members of each group to come up with a practice that could significantly improve the shared understanding with their customers. Five groups independently came to the same conclusion: “Spend some time working at the customer’s location.” Continue Reading »

| View | Upload your own

Kuniaki Igarashi posted a nice presentation on Omoiyari-Driven Development, with the core idea of programming while keeping in mind how other developers are going to use and understand your code. This practice aims to reduce misunderstandings among team members. I have a strong belief that communication and communication-related problems play a key role in software development, and although I would not consider being thoughtful of others as an idea that can lead development, I certainly agree with Kuniaki that it is a very important practice. I wrote several articles about related techniques, including Documentation for telepathic developers and The Poka-Yoke principle and how to write better software.

I am pointing to this presentation mostly because of the secondary “Bear programming” practice, which revolves around explaining the problem first to an imaginary team member (or in this case a real stuffed toy bear) before raising the flag and asking for more help. When a team member asks a question that clearly signals that he misunderstood the issue or the underlying infrastructure, I always try to lead that person into expressing the problem better or drawing it on paper. Very often that team member will reach a good conclusion himself – expressing it on paper or to another person just helps to clear the issue in his mind. This is, in my experience, much more effective than just giving an answer straight away. Bear programming speeds up the process a bit and includes a virtual person for people to talk to.

A stuffed toy is, however, no replacement for an experienced team member – and if agile development has thought us anything it is that there is no replacement for direct person-to-person communication. Asking for help is a good thing and I would not want to prevent people from doing that. But this can be a very useful practice to prevent junior team members from wandering off into the wilderness when they hit a problem. I would suggest using Bear programming, but with a different trigger – before starting to develop some utterly complex workaround, explain the problem to the bear. If that does not help, then raise the flag and call someone to assist you. Using the commander’s intent template can also help a lot to improve the shared understanding – so if you are often getting these problems ask yourself whether you can explain stuff better in the first place.

How do we sell the test-driven approach on a wider scale to business analysts and customers? How do we get them involved in that process? It seems that a lot of the problems and confusion obstructing that effort come out of the misleading name of the term “acceptance tests”.

Dan North suggests using the word “behaviour” instead of “test” to point out how acceptance tests express system behaviours. I found this approach very useful for describing the role of TDD to “outsiders”, who are not interested in low-level functional testing and tune out as soon as people start talking about anything related to testing, including Test-Driven Development. Dan writes: Continue Reading »

From /dev/coffee to modeling transaction processing based on Starbucks shops, the world of coffee has often inspired programmers. Here is a not so bright example from the world of coffee, giving us a hint how problems should not be solved. We recently bought a new coffee machine, and after a glance at the user manual, I was amazed to find out that our new Gaggia was affected with a common flaw of enterprise software: ignoring “stupid” problems.
Continue Reading »