People have tried to define programming since forever. Is it art, engineering, or perhaps craft? It may be that it's all, or neither. I tend to think about it more like gardening than craft or engineering or art. This is because software tend to take on a life of its own over time. This may sound a bit odd to some. But think about it a bit. Perhaps it will start to make sense.

As we work on a piece of software over time there are usually several different people who work on it (even if that's several incarnations of you). Each different author add their own thoughts and directions to the software. With some skill the people working on it will be able to keep it together enough that everyone feels at home. But for each incarnation of the software it changes a bit.

As software people we are often tasked with estimating how much work/time/money something is likely to require. I know that many of us feel this is difficult at the best of times, and often impossible. But is there a better way to answer the questions of how much and how long? And how harmful can estimation actually be, if the customer needs it?

I'd like to argue that story estimation, using story points or time or whatever else, is harmful. Also, I'd like to argue that it does not answer any of the questions the customer have with regards to how much.

I often introduce Gherkin to teams when I work with them. Naturally they then want to know why. So I think it's time I write that down.

Let's start with a brief description of what it is. Gherkin is a formal language (just like programming languages are formal languages) which is used to capture specifications is plain spoken language. It describes features using scenarios which in turn are made up of constructs like given, when and then.

I've seen organisations try to roll out Agile in many different variation over the years. Yet I don't see many being successful. Some come to the conclusion that Agile doesn't work. Others seems to find the new practices that came with it works well enough so they continue but they don't reap any of the promised rewards.

Many have written and talked about this before me. But I'm going to add my tuppence worth. Perhaps it will help someone to a better understanding of what it is that doesn't work, cause it's not Agile that's not working.

We as individuals create self-deceptions to make life easier to deal with. So do organisations. I've worked for many organisations who have said they hold to a set of values but they do not conduct their work in accordance with them. When I challenge them on the topic I am often met with hostility or a blank face.

What I am finding is that when organisations behave like this it creates a destructive environment to work in. My tolerance level for such things is pretty low and when I find that others don't listen it usually ends with me leaving. I know I am not alone in this. Many that I've met who are good at their job seem to act the same way. Since it is easy for us to get another job we move on. The work involved in making an organisation, where most of the people in the organisation are complicit in the self-deception, understand that they do not live by their values is just too much work to be worth it. But I usually find it worth to at least try.