At your service, master!

One of the most important lessons that I had to learn in my job is that you have to be aware of the client. As a service provider, it is my duty to satisfy my client’s needs – and without knowing him, I will not be able to succeed. In this blog post I describe some insights that helped me to gain a better understanding of my clients.

The main connection between the service provider and his client is the communication between them. In an ideal world, the two parties would be able to understand each other perfectly, however, humans and their language are fallible and to me, this seems to be the root of most problems. Of course, both parties are responsible, nevertheless, the service provider should not only deal with his own defeciencies, but also with his client’s, in order to attract and keep clients. Next, I will list five instructions that can reduce or sometimes even prevent the incomprehension in the communication.

Be prepared

This is maybe the clearest rule: Before meeting a client, you should know the basics of the domain he is working in and of the problem he wants to solve. It is not the client’s job to explain his request, but rather the service provider’s job to comprehend it. Besides, if a client feels understood, he will also feel that you can solve his problem – and at that stage this matters more than whether you can actually solve his problem.

Be attentive

You and your client are different persons and, as a result, have a different understanding of the same things. Your client might quickly slur over some little details in a software he wants, so you could assume that they are of no importance – but you will be unpleasantly surprised when it turns out to be a critical aspect of the program. And this is not necessarily a flaw in the customer’s communication: Maybe to a domain expert – and your customer might be one – the importance of these details is totally obvious.

Furthermore, sometimes even language will lead you nowhere. For example, people do not always realize why a system is hard to use or where they make mistakes and hence cannot tell you about it, but by watching them you might find the problems. In such a situation, it is crucial to grasp not only the words the client is saying, but also other signals he is emitting.

Be without bias

As soon as I start listening to a client’s problem, sometimes I can literally watch myself constructing a solution in my head. I create a mental model composed of the components the customer is talking about, think about their relationships – and suddenly, I find myself thrown a curve because the client added a thought that objects my conception.

Of course, a model can improve the understanding of a client’s demands, however, one has to constantly question the validity of the model and – in case it is disproved – one must drop it without hesitation. Do not become attached to a model just because it is so elegant – in most cases, you will be betrayed. In contrast, it will probably become easier to adapt your mental models if you stay open-minded.

And even if your view seems to suit the customer’s requirements perfectly, you should hesitate to present it to him, you should not ask for confirmation early on. In fact, the better the concept seems, the more careful you should be: You might lead your client into thinking that it is a adequate solution, and by focusing on the conformity between the concept and his problem, you and your client may fail to see flaws.

Instead, you should try to ditch your assumptions, try to listen without bias. You still have to prepare yourself before you meet your client, but you should be willing to scrutinize your knowledge and to discard incorrect information.

Be concrete

The human language is a wonderful medium, but unfortunately terribly inaccurate. If, instead of writing, you can talk with your customer, you should usually choose the latter. Even better, if you can meet him in person, do it – there are so many more options to communicate if you are in one room that you will almost surely benefit from it.

For instance, if your client wishes a feature with some user interface, you can sketch it or build a paper prototype; you could even prepare a real prototype consisting only of the user interface. This allows your customer to play with it and facilitates the communication. And do not be abstract, do not fill your widgets with texts as “Lorem ipsum” – it does not matter if the content is made-up, but it should be realistic.

User interface design is a neat example since it is graphical, nevertheless, you can apply this principle to other tasks. It does not matter if you talk about a processes, some architecture, domain models or other structures: Even though most of them have no inherent graphical representation, it is usually easier to describe them graphically then by using text.

Seek for the why, not the what

Often, I tend to ask my clients about the problem they wish to solve – I ask what they wish to solve, not why. Usually, this is sufficient; he knows his situation and is able to express his needs. Unfortunately, it also happens that albeit the customer’s problem is solved according to his description, his wants are not satisfied – and the reason for this is that even he did not know what he actually needed. Even worse, sometimes I get caught by the “how”, that is, I quickly find a nice solution for some parts of a client’s problem, so I stick to it, maybe even implement it – and in the end I realize that it actually prevents me from solving the complete problem.

Hence, it is not only important to find out what your client wants to achieve, but also why he wants to achieve it, you have to understand his motivation. This can enable you to correct your client’s mistakes and to lead him to the question he actually wants to answer. Furthermore, this is a great handle to control the effort of a project: It becomes easier to identify indispensable core functionality and to find features whose usefulness is questionable, and hence, one can communicate with the client if some of the latters might be dropped. Simon Sinek gave an interesting TED talk to a similar topic found here.


Understanding your customers is difficult, but not impossible. I think that actively directing the attention at your counterpart, being open for input and questioning your assumptions and knowledge can strongly improve the communication with your clients.

Three essential developer values

We reflected on the inner values of our team and came up with a short list that might sound trivial to you, but is honest in its motivation.

value-coinThere is the notion of “professional attitude” in software development. In the recent years, the agile movement, the craftsmanship philosophy, the pragmatic approach and the clean code developer initiative all tried (and certainly kind of accomplished) to install a set of values in developers. Most of these values are important and probably self-evident to those of us that can transcribe them into actual work decisions. It just feels right to do certain things or do something a certain way.

Local values

But what if you are challenged to articulate your own core values without using a common template like “the values of the clean code developer”? Let’s say that recurring conflicts force you to spell out the (in your view) most self-evident things to be able to describe the root of your unease. Every group of collaborators shares a set of “unspoken laws” and common beliefs that lay below the threshold of conscious application and are hard to describe to outsiders. We reflected on these core values in the last time and came up with a set of “local values” that are important to us. This blog post tries to explain them.

Probably trivialities

Before I list our three essential developer values, I want to damp your expectation about a great revelation and a whole new set of values that nobody’s ever thought about. All the value set templates listed above had and still have a great influence on us and are explored in our daily work. So you’ve probably already heard about every thought we could come up with. And our results are probably trivialities to most of you. That’s great! We didn’t set out to research something new, we tried to articulate our most mundane motivations and standards.

The three values

The following list is ordered. I start with the least of the three values and end with the most important one. That’s not to say that this list includes all values of ours, it just lists the three most important ones to adhere to the spirit of brevity (and relevance).


Yes, efficiency is the third most important skill to master when working with us. It’s a platitude in the sense that “you should be efficient” – of course you should. But we defined some aspects of efficiency that are vital to our work culture. Our developers need a heightened capability of self-inspection in regard of “being stuck”. You know that feeling when your work breaks apart into an overwhelming amount of tedious little steps? Or when you always feel like success is right around the corner, but always just out of reach? That’s just two of many aspects of getting stuck. We expect our developers to raise their hands and ask for help as soon as they sense the faintest amount of “stuckness” in their work. It takes a lot of self-confidence to admit that the task at hand is too much to handle alone, at least right now. We don’t count your report of being stuck as a personal failure, but a team-wide possibility to gain efficiency by reducing waste (wasted time in this case).
To avoid getting overwhelmed by a task in the first place, we expect our developers to assess their abilities and “readiness” towards a specific task and give an honest evaluation if they think to be “the right one for the task”. There again, pride and over-confidence can prove utterly destructive and diminish overall efficiency.


While communication itself is a tool, not a value, we rely on the proper application of this tool enough to value it our second most important trait to master. The most important question to ask is “has anybody done something similar yet?”. There is no point in re-inventing the wheel or re-learning the same lessons again and again. Don’t make assumptions – ask for specific details if necessary. Don’t be afraid to appear dumb – you’ll look even dumber if you didn’t ask and screw up. There are many aspects to communication that can go wrong.
In accordance with the efficiency value, we also expect you to be proactive to report problems or even uncertainty. Every failure contains a failure in communication. Even if you can just announce that everything goes smoothly up to this point, this is an information worth noting. After each waypoint or iteration in your current task, make a commit and leave a comment in your issue. Stay in touch with your team and don’t retreat into a “me against the world” kind of solitude. In short, we expect our developers to be open, honest and proactive in their communication.


Our most important value is reliability in the sense of trustworthiness. We want and need to trust our developers, their estimations and commitments and the repeatability of their successes. There is no benefit in “faking it” or taking credit for something you achieved by pure luck. We try to have a working atmosphere were we can rely on another, trust another and also be open with our shortcomings. There is no need to pretend, for we will ultimately see through the ruse. We want our developers to contribute to the team, not to groom their ego. In a reliable work relation, you can trust the other to deliver what was mutually agreed upon or report problems at the first moment possible. And you can expect to be valued and commended for “just doing your job”. There is a lot of the craftsman ideology in this approach and it ultimately resolves to the commandments of egoless programming. The result is a fearless, positive environment for everybody to develop their unique abilities and strength. And don’t you worry about your weak points – the team got you covered.


I hope that my shortcomings with the english language didn’t stop you from grasping the core concepts of our local value set. We mostly apply it subconsciously and definitely aren’t perfect in any aspect. But just to articulate our deeper motives helped a lot to dissect certain conflicts and gain a broader understanding exactly why we do certain things. I don’t suggest you should adopt our values, that wouldn’t probably work out. But I encourage you and your team to invest some time to reflect on your local value set and try to find a mutually understood verbalization of them. If you can share your insights on this topic, please leave a comment! We would love to hear from you.

Communication through Tests – a larger experiment

We evaluated our ability to communicate through tests in a two-day experiment and gathered some interesting results.

triangulatorFor us, automated tests are the hallmark of professional software development. That doesn’t mean that we buy into every testing fad that comes along or consider ourselves testing experts just because we write some tests alongside our code. We put our money where our mouth is and evaluate our abilities in writing effective tests.

One way to measure the effectiveness of tests is to try to “communicate through tests”. One developer/team writes code and tests for a given specification. Another team picks up the tests only and tries to recreate the production code and infer the specification. The only communication between the two teams happens through the tests.

We performed a small experiment with two teams and one day for both phases and blogged about it. The results of this evaluation was that unit tests are a good medium to transport specification details. But we got a hint that problems might be bigger when the code was less arithmetic and more complex. As most of our development tasks are rather complex and driven by business rules instead of clean mathematical algorithms, we wanted to inspect further.

Our larger experiment

So we organized a bigger experiment with a broader scope. Instead of two teams, we had three teams. We ran the phases for eight instead of two hours, essentially increasing the resulting code size by a factor of 3. The assignments weren’t static, but versioned – and the team only knew the rules of the current version. When a team would reach a certain milestone, more rules would be revealed, partly contradicting the previous ruleset. This should emulate changing customer requirements. And to provide the ability to retrospect on the reconstruction phase, we recorded this phase with a screencast software (we used the commercial product Debut Video Capture), capturing both inputs and conversation by using headsets for every developer.

The first part of this experiment happened in late January of 2013, where all teams had one day to produce production and test code. This was a day of loud buzz in our development department. The second part for the reconstruction phase was scheduled for the middle of February 2013. We had to be a bit more quiet this time to increase the audio recording quality, but the developers were humming nonetheless.

Here are some numbers of what was produced in the first session:

  • Team 1: 400 lines of production code, 530 lines of test code. 8 production classes, 54 tests. Test coverage of 90.6%.
  • Team 2: 576 lines of production code, 655 lines of test code. 17 production classes, 59 tests. Test coverage of 98.2%.
  • Team 3: 442 lines of production code, 429 lines of test code. 18 production classes, 37 tests. Test coverage of 97.0%.

The reconstruction phase was finished in less than five hours, partly because we stuck very close to the actual tests with little guesswork. When the tests didn’t enforce a functionality, it wasn’t implemented to reveal the holes in the test coverage. This reduced the amount of production code that had to be written. On the flipside, every team got lost once on the way, loosing the better part of an hour without noticeable progress.

The results

After all the talk about the event itself, let’s have a look at our results of the experiment:

  • The recording of the reconstruction phase was a huge gain in understanding the detailed problems. We even discussed recording the construction phase too to capture the original design decisions.
  • Every decision on unclear terms from the original team lead to “blurry” tests that didn’t guide the reconstruction team as good as the “razor-sharp” tests did.
  • You could definitely tell the TDD tests from the “test first” tests or even the tests written “immediately after”. More on this aspect later, but this was our biggest overall take-away: The quality of the tests in terms of being a specification differed greatly. This wasn’t bound to teams – as soon as a team lost the TDD “drive”, the tests lost guidance power.
  • Test coverage (in terms of line coverage or conditional coverage) means nothing. You can have 100% test coverage and still suffer from severe plot holes in your tests. Blurry tests tend to increase the coverage, but not the accountability of tests.
  • In general, we were surprised how little guidance and coverage most tests offered. The assignments included some obvious “testing problems” like dealing with randomness and every team dealt with them deliberately. Still, these were the major pain points during the reconstruction phase. This result puts our first small experiment a bit into perspective. What works well with small code bases might be disproportionally harder to achieve when the code size scales up. So while TDD/tests might work sufficiently easy on a small task, it needs more attention for a larger task.

The biggest problem

When talking about “plot holes” from the tests, let me give you a detailed example of what I mean. The more useless tests suffered from a lack of triangulation. In geometry, triangulation is the process of determining the location of a point by measuring several angles to it from known points. When writing tests, triangulation is the effort to “pinpoint” or specify the implementation with a set of different inputs and required outputs. You specify enough different tests of the same functionality to require it being “real” instead of a dummy implementation. Let’s look at this test:

public void parsesUserInput() {
  assertThat(new InputParser().parse("1 3 5"), hasItems(1, 3, 5));

Well, the test tells us that we need to convert a given string into a bunch of integers. It specifies the necessary class and method for this task, but gives us great freedom in the actual implementation. This makes the test green:

public Iterable<Integer> parse(String input) {
  return Arrays.asList(1, 3, 5);

As far as the tests are concerned, this is a concise and correct implementation of the required functionality. And while it is obvious in our example that this will never be sufficient, it oftentimes isn’t so obvious when the problem domain isn’t as familiar as parsing strings to numbers. But to complete my explanation of test triangulation, let’s consider a more elaborate implementation of this test that needs a lot more work on the implementation side (especially when developed in accordance with the Transformation Priority Premise by Uncle Bob and without obvious duplication):

public void parsesUserInput() {
  assertThat(new InputParser().parse("1 3 5"), hasItems(1, 3, 5));
  assertThat(new InputParser().parse("1 2"), hasItems(1, 2));
  assertThat(new InputParser().parse("1 2 3 4 5"), hasItems(1, 2, 3, 4, 5));
  assertThat(new InputParser().parse("1 4 5 3 2"), hasItems(1, 2, 3, 4, 5));
  assertThat(new InputParser().parse("5 4"), hasItems(4, 5));
  assertThat(new InputParser().parse("5 3"), hasItems(3, 5));

Maybe not all assertions are required and maybe they should live in different tests giving more hints in their names, but you get the idea: Making this test green is way “harder” than the initial test. Writing properly triangulated tests is one of the immediate benefits of Test Driven Development (TDD), as for example outlined nicely by Ray Sinnema on his blog entry about test-driving a code kata.
Our tests that were written “after the fact” often lacked the proper amount of triangulation, making it easier to “fake it” in the reconstruction phase. In a real project setting, these tests would allow for too much implementation deviation to act as a specification. They act more as usage examples and happy path “smoke” tests.

Our benefits

While this experiment doesn’t fulfill rigid academic requirements on gathering data, it already paid off greatly for us. We’ve examined our ability to express our implementations through tests and gathered insight on our real capabilities to use test-driven methodologies. Being able to judge relatively objectively on the quality of your own tests (by watching the reconstruction phase’s screencast) was very helpful. We now know better what skills to improve and what to focus on during training.

Where to go from here?

We plan to repeat this experiment with interested participants as a spare-time event later this year. For now and ourselves, we have gathered enough impressions to act on them. If you are interested in more details, drop us a note. We could publish only the tests (for reconstruction), the complete code or even the screencasts (albeit they are somewhat long-running). Our participants could elaborate their impressions in the comment section, if you ask them.
We are very interested in your results when performing similar events, like Tomasz Borek did this month in Krakow, Poland. We found his blog entry about the event to be very interesting. We definitely lacked the surprise element for the teams during the event.