Software development is meant to be fun, if it isn't, the process is wrong

El desarrollo de software se supone que es divertido, si no lo es, el proceso es incorrecto

– Johann Wolfgang von Goethe

One element of Cucumber feature-writing that is often neglected is the role. This is the section that sits between the well known In order that and I want to.

It’s very easy to concentrate on what we wish to accomplish, and why we want to do it. The role that we’re in, however, affects the way that we do it, and how the action is perceived as it is carried out. It is in fact, the key to user experience of the feature.

How often have we lazily written features like this?

In order to know how much money I am making
As a user
I want to see a report of widgets sold this month

What we want is clear, as is why we want it. What’s not clear is who is doing the asking, and therefore there’s no clue as to what the user experience should be like.

A sprinkling of personality

Next time we find ourselves writing “as a user”, let’s take a minute to stop and think whether we can be more specific.

Consider this feature:

In order to know how much money I am making
As the head of the company
I want to see a report of widgets sold this month

This guy is time poor, and just wants the facts, right now. Sure, he might want it to look good, but doesn’t care much beyond the numbers.

Now how about this one?

In order to know how much money I am making
As a design assistant responsible for collating reports
I want to see a report of widgets sold this month

This person possibly has a little more time on their hands, and their overriding concern might be to impress their boss. Therefore the aesthetics of the report layout might be very important, and it might not matter so much if the page is slower to load.

Personas driving stories

On a recent project for a coaching company we took this a step further. We produced some great personas during the inception (Bob Coachee, Jean Coach), and then went so far as to use them in our features:

In order to know who I am coaching next
As Jean the coach
I want to see a calendar showing today's appointments

Because everyone on the project knew the background behind these characters, the resulting features communicated a lot of knowledge. We all knew exactly how they were using the system, and what they needed out of it. We had about six personas in total, and they proved very helping in communicating the user experience of the feature to the team.

Do you create specific personas for your projects, and have you ever used them when writing your features? Did you see a benefit?

How much you want to do it   =   Confidence you can do it   *   Perceived Value of doing it
                                 ----------------------------------------------------------
                                 Proneness to being distracted * How long you have to do it

I’d be grateful if anyone can source this for me, as I can’t find the reference and would love to link to it!

It seems simple enough, but it’s suprisingly effective at helping us out of a motivation pit. We’ve all had times when we have had something we need to do, yet we cannot seem to bring ourselves to get on with it. It’s like we’ve fallen into a pit of despair about a certain task and cannot get out.

So what can we do to boost our motivation? This formula gives us a few tools to help us complete that task. They’re listed here in the order in which I’ve found them useful:

Break it down. If it’s too big to imagine completing it, break it down: what’s the next thing you can do to progress it? Do that, then rinse and repeat. This is one of the main things I learnt from GTD.

Ensure you can do it. This is all about raising our confidence in whether we can get it done. Remind yourself that you have ability and knowledge to not only do it well, but knock it out the park! If you don’t, either get someone to help you with the task or schedule another task to find out what you need to know. Both these things will raise your confidence and increase your motivation.

Remind yourself why you’re doing it. In other words, raise your perception of the value gained through doing the task. What is the task achieving for your? What good things will happen when it’s done? Remember, the tasks you feel the least like doing are the ones you feel best about having done: there’s value in that in itself. After this, if you still cannot see the value, why are you doing this in the first place?

Reduce distractions. Some distraction is inevitable, but we can work hard to overcome it. This is where I’ve found the pomodoro technique very useful. Change your environment and space to help you concentrate on what you’re doing. Tracking your distractions and intentionally overcoming them can be very effective in helping to get something done.

Raise the bottom. When do you have to do it by? If it’s in six months time, then you’re unlikely to want to bother now. But if the task is going to take six months (such as writing a dissertation, for example), then you will naturally doubt you can do it, and you’re really going to struggle to get started.

Instead, break the task down, and think: “If I’m going to get this done, I have to do this first thing by next week at the latest.” That will raise your confidence level (smaller task) and artificially reduce your deadline, both increasing your motivation.

Do it later. In a week you’ll have less time to get it done, and therefore you’ll be a bit more motivated. I’ve found this is the least effective, as it plays into my natural tendency to procrastinate, but sometimes we have to question why we’re doing this now at all, and get on with the really important tasks.

Hope this formula helps you as much as it’s helped me.

I wonder about how scalable the apprenticeship model is. It seems to be predicated upon mentorship, where each apprentice has a mentor. This means you need a large number of mentors if you have a large number of apprentices. They will have to be found and paid. This will cause difficulties... If you want 1 teacher per 10 students you'd have to find an pay 10 times as many as now. How does the Software Craftsmanship movement intend to deal with this?

Buried in this problem is an inherent assumption about the way programming is taught. It assumes the current university model of teaching undergraduates: employing researchers who spend most of their time away from their students doing what they’d really like to be doing, whilst having to teach classes to pay the bills.

If you try and use an apprenticeship model in this context, you run into severe funding issues: who will pay for all the extra researchers?

A different way

Why don’t universities do real software projects? Why can’t we have master practitioners being paid by real clients to do real work, and have the students along for a ride, learning as they go?

The funding issues will be cleared up as business will be paying. Students work for free, or perhaps room and board. Either way they won’t be saddled by exhorbitant fees.

If this makes sitting in a lecture hall listening to information difficult to fund, then great. That’s one of the most inefficient ways to learn: why do we persist in trying to sustain it? There is value in book learning, and the industry does currently rely on students to achieve that through university education. But the best way to pick up those principles is through real-world examples on real projects, supported by appropriate exercises designed to drive home specific points. It is certainly not through sitting in a lecture hall.

Maybe this model is a step too far for a traditional university. Perhaps they’re not be the best place to learn our craft. Our current university system is designed to create great professors, not great practitioners. Perhaps it’s time for a change.

Unless we’re in the unenviable position of hiring or firing team members, then we don’t have to worry about individual team performance. When I asked how many people at the recent software craftsmanship gathering were in this position, less than 10% of the people there put their hands up. Chances are it isn’t our job to worry about any individual’s performance except our own.

The team is the atomic unit of success or failure. When individuals screwed up at Eden, I used to say that I wasn’t interested in whether they’d made a mistake, as mistakes are guaranteed to happen. What I’m more interested in is what caused the mistake to occur, and that they used the experience to improve the process or their own practice.

Your team or business is perfectly designed to achieve the result you are currently getting. I’ve heard of people being fired on the spot for making mistakes. What a waste of all the learning they’ve just experienced.

So next time Bob breaks the build (again), let’s have a look at why. Is it because he’s new to the team and no-one has told him how important a passing build is? Is it because the clients put him under a lot of pressure and he didn’t feel that he had time to run the tests? If it’s because he’s forgetful and careless, how do we mitigate for that weakness? For example, would encouraging Bob to pair program help?

Even if it does appear to come down to an individual issue, there are still process improvements to consider. Are we hiring slowly enough? Are we checking properly for a culture fit? Are we involving the team enough in pre-hire decisions?

Each of these questions facilitates a team culture change: Bob didn’t screw up, the team screwed up by not having quite the right culture or process, and the team will fix it.

Clearly there are some cases where individuals need to be dealt with personally by those responsible, but it’s less often than we think and normally not our problem. Let’s not make it our problem and further destabilise our teams through a damaging witch hunt.

– Benjamin Franklin

It is often argued that certification is a bad thing. I would say that certification is not good or bad: it is rather the certifier and the manner of the certification that can be good or bad.

Certification is just recommendation mass produced.

Recommendation is very valuable, but only if I trust the recommender. If a trusted friend recommends the work of another, I will listen hard. If that recommender is a faceless corporation, then I won’t pay so much attention. If that corporation has been paid to recommend someone to me, then I will pay even less attention.

I suggest we seek to win the recommendations of trusted people through a good track record, rather than paying a corporation to recommend (read: certify) us. Those who have mass produced their recommendations through a paid certification scheme are not likely to carry weight with anyone after a while.

– Antiphon the Sophist

The concept of time is a difficult one to pin down. Through centuries the devising of a non-controversial way of defining it has eluded even the greatest scholars. I’ve been learning a bit about time from my use of the pomodoro technique recently, and I want to discuss two ways that we perceive time, specifically as it relates to getting stuff done.

The concept of “becoming”. This is an abstract, dimensional way of seeing time. It gives rise to the measuring of time in minutes and hours, and the idea of “not having enough time” or of “being late”.

The succession of events. The concept of something being “before” or “after” something else: I do this, then I do that. As children, this is the first understanding of time we grasp, before we learn about the abstract concept.

Why does this matter?

The abstract concept of time is what creates stress. We worry that there’s “not enough time in the day”, or that we’re “wasting time”.

Contrast this: ”I’ve been waiting seven hours for my iPad, and I’ve only just got it!” with: “I waited in line, and then I got my iPad.”

Viewing time as a success of events creates rhythm. There’s a certain natural orderly progression when talking about succession: I got up, I had breakfast, I went to work, I phoned Bill, I cleared my inbox, I had lunch, I queued, I bought an iPad… It’s calming and relieves anxiety.

How can this make a difference?

Next time you’re stressing like crazy because you “only have 3 hours left” before the end of the day to get a lot of things done:

Stop. Worrying will make it worse; you’ll have even less time after you’re done.

Work out what you can realistically achieve today. Renegotiate everything else. You’re not going to get it done anyway: why not let people know sooner rather than later?

Write down a list in order of what you’re going to do. Put “go home” at the end of the list.

Follow the list. Don’t pay much attention to the seconds and minutes. Go home when it tells you to.

The subtler aspects of the Pomodoro technique are teaching me a lot. Thanks to Bergson and Minkowski as cited by The Pomodoro Technique book for the raw intel.

Henri Bergson, L’evoluzione creatrice, Cortina Raffaello, 2002; ISBN 88-70-78780-X.

Eugène Minkowski, Il tempo vissuto, Einaudi Editore, Torino, 1971; ISBN 88-06-30767-3.

set encoding=utf-8

filetype indent on
set tabstop=2
set softtabstop=2
set smarttab
set expandtab
set autoindent

set number

set backspace=indent,eol,start

set ignorecase
set smartcase

set incsearch
set hlsearch

nnoremap <leader><space> :noh<cr>