A Thought on Design Patterns

We were told a design pattern is a solution of a problem in a given context.

The metaphor above focuses our thinking on a space of a given problem. But if we extended a view a little more, we would see there is one more thing: tools.

So, a design pattern is a solution of a problem in a given context with given tools usage. And tools are obviously programming languages we use. Observing programming languages evolution (as I remember a great piece of it was given here), we may arrive at the conclustion that design patterns try to solve lacks of programming languages.

From this point of view moving to a next programming language may cause a problem disappears.

So don't try to introduce patterns to solve the problem you faced with. Find a technology where the problem is gone. This is a way I understand the Polyglot Programming movement. I think it is the right direction.

Please, define your organisational values

Dear HR Director,

I decided to write this letter, because for over five years I have worked with software engineers on their effectiveness and seen how organisational values influence software developers work.

Probably you have defined a mission statement and values in your organisation. But did you ever noticed their correlation to a quality of the source code or development processes?

Developers too often take organisational values with a grain of salt. They tell me these are just only "posters" on the walls or on their screen savers. But for me - an outer observer - it definitely is obvious that a mission statement and organisational values do their job. And do it well.

So, what I have seen? Organisations where values statements looks like:

• We put our customers first
• Our success is customers satisfaction
• A customer can't wait
• We are professionals
• We do everything for our customers

and that is all, that organisations mostly (I said: m o s t l y) have a lot of multitasking and technical debt inside. That two lead to the even more multitasking and more smelling code as a consequences.

To be precise: all values above are good. I would be proud to identify myself with one of them. But, the problem is the values are not defined clearly enough. Engineers, managers and non-technical stuff simply do not know what to do. They try to satisfy organisational values so much, so they do just only one thing possible to be done: they guess what to do.

Of course, every individual guesses on its own account. In addition clients and deadlines bring the pressure to the teams. And here a multitasking and lack of decision making start working on software quality.

So please, define your organisational values. Define at least:

• What kind of behaviours are acceptable
• What kind of behaviours are not acceptable

I emphasised "behaviour" word on purpose. You have to be precise. People do not understand "be professional" but they clearly understand "do a code review". And last but not least - do what you said.


Yours sincerely,
Michal

Conversation Patterns: A User Story Template Revisited

This article is part of my work on Conversation Patterns for Software Professionals

---

This is well known user story template:

As a [role]
I want [feature]
so that [benefit]

But I noticed that because of this template teams focus mostly on features. What is wrong with that? However, discovering the right features is the goal of user stories, but at the same time a benefit part is neglected.

Consider following (anti)stories:

• As a User I want to login, so that I use a system
• As a User I want to print report, so that I can do my job
• As a User I want to click RMB, so that I choose wanted option from the context menu

These are examples of stories where a benefit part was not clarified enough. Again, what is a big deal?

In general a benefit is a need and another type of a need is a problem to be solved. So, a role wants a feature because one requires a benefit or problem solution. This is natural feature - business need relation.

A feature is a way to satisfy business need by the software functionality. Having need clearly defined a team and PO are able to discover set of features satisfying business need and choose the best one.

But using a given user story template we start a conversation from a feature without talking about a business need first.

Then we want to fill a template so it is possible to put some general benefit instead of, you know, the "real" one.

My solution is: use a slightly different user story template:


In order to [benefit/problem to be solved]
I want [feature]
Being a [role]


---

UPDATED@10/03/2014
Upon further study I decided to redesign the given template as follows:

In order to avoid [problem to be solved]/In order to achieve [expected benefit]
As a [role]
I want [feature]

So now we have two US templates for each of stakeholder's need favour.

---

This template helps to focus on business need first. When the one is clearly defined you may start discovering possible features to satisfy the need.

Conversation Patterns: A Buffer of Useless Answers

This article is part of my work on Conversation Patterns for Software Professionals

---

So you're talking with a stakeholder about new backlog items. Which of the following questions you are going to ask:

1. Do you want to add new items to the backlog?
2. What of new items you want to add to the backlog?
3. What of new features you're going to use next week?

You must always consider stakeholder answers as a result of your questions. So the better question you ask the better answer is given to you.

Choosing the first question: Do you want to add new items to the backlog? you indirectly define possible answers. These are: yes or no. Answering that question is not an effort, so your stakeholder will do it automaticly, without thinking a lot. One will take an answer form a buffer :)

I imagine every human being has a special area in its mind where all answers comes from. Stakeholder is trying to optimize energy when one is querying for the answer, so an 'answer area' is divided into two subareas: surface area and deep area.

The surface area I called a buffer of useless answers. When you ask the question a stakeholder tries to find an answer in this buffer first (to optimize its energy, of course).

The problem is what a buffer contains. Well, rubbishes in most cases: parts of memories, parts of conversations, random informations. A buffer of useless answers is like an uninitialized variable in C - it may contain anything :).

So, to get quality answers you have to drill deeper under the buffer of useless answers. How to do it? Well, ask a question with a suggestion where or how to seek an answer.

Consider the second question example: What of new items you want to add to the backlog? There is an assumption in the question: I know you want to add some items. A stakeholder is not instructed to take an answer from the predefined set of answers. Finally, one will make an effort querying a deep answer area, not a buffer of useless answers.

You may decide to drill even deeper. The third question example is: What of new features you're going to use next week?. Oh, yeah! A stakeholder's brain is red hot now. One was instructed to imagine oneself of act of using a software in the future. One tries to place priority features among the existing ones. Then one verify a usability of whole new mental model and then is ready to answer the asked question.

What questions you might to drill deeper?