Tag: Software development

Expressing Expectations

Long long ago, while preparing experiments for my diploma thesis in physics, my tutor taught me to express my expectation of the outcome of experiments before actually running them. I was to not only to express them in my head, but speak them out loudly, may be even make a note.

This helped a lot, when figuring out where my thinking didn’t match the experimental evidence. There was no denying when my expectation differed from the empirical result. Typically, there were two sources for the differences:

  1. My mental model wasn’t good enough to match the result of an experiment.
  2. The experimental setup wasn’t designed well enough to show the effect I was trying to measure.

I find that this is still working well in software development (both the coding part as well as testing). A related article about this is Peter Naurs seminal paper ‘Programming as Theory Building’.

When doing TDD (test driven development), explicitly expressing the outcome before running a test may not always lead to a surprise. In the very beginning, when a test tries to create an object, without having a class definition, it will cause an error message that is easy to predict.

However, when work has progressed a bit, I regularly run into situation where I expect the next new test to fail in a certain way, but when running the test, the actual error message is a surprise to me. These are situations where learning can happen, by figuring out why the actual behaviour does occur, instead of what I predicted.

Near the end, the surprise is caused differently: I’ll write a new test and expect it to fail. – It doesn’t. Again, this is a good reason to explore why exactly I thought the test would fail.

Particularly in a pair (or ensemble) programming setup, the inability to come up with a new failing test is a sign, that the implementation is good enough … for now.

Recently, I did a programming exercise as part of a technical interview, and expressing my thoughts and expectations while working on the code helped me to find a solution. Additionally, the interviewer didn’t only see what I was typing, but could follow my way of thinking. This relates to Naur’s paper mentioned above: The testing and tested code I wrote isn’t everything there is to my mental model of the given problem or its solution. The way of thinking is important too. This is why I find vocally expressing my expectations & thinking while actually doing the work.

What are your preferred way to actually do the work you’re doing? I’d love to hear about it.

The Opposite of ‘More of Something’ Is Not Less of It

One pattern I see often is that people (me included) apply more of some X, if applying the usual amount doesn’t yield the desired result (anymore).
Two examples from very unrelated fields:

  1. If a dog or other pet doesn’t react in the desired way to a command (‘sit’, ‘down’…), many people start shouting at the dog again and again, which may or may not work at first, but will also fail eventually. Stopping to shout at the poor dog won’t solve the problem either.
  2. In software development I’ve seen rules and policies added to a given process again and again. In these cases the goal was to make the teams produce better products faster (and probably more predictable). That doesn’t lead to the desired results either. But reducing the number of rules is not enough to get teams out of trouble.

So when X doesn’t work, or doesn’t work anymore, applying more of it won’t help. Alas reducing it (less/no shouting at the pet, removing process load from projects) won’t solve the issue.

It seems to be a lot more promising to try an entirely different approach. After realising issues with waterfall projects, we (as software developers) found agile methods to be helpful. In the case of training a dog it’s another way to help the dog learn a new command. In some cases it may even be necessary to teach it its name before.

Did you see anything like this? Let me know.

Navigation

%d bloggers like this: