The 7 Duties of Great Software Professionals. Really?

There are two reasons I am not a fan of this talk. First, once you saw Anthony Robbins' motivational speech you don't want to see anybody else. He is simply the best!

The second reason is that in this speech the author offers some challenges to developers, he suggest that setting and achieving professional goals is the way a developer should follow to become great.

Well, goals are very popular and well known self-motivation tools, but they sucks. Why?

Setting the Goals

Being driven by goals is endless race from one goal to the next one, and then when your first excitement is behind you, you may wonder: What was actually for?

As Paweł explains (in Polish) achieveing a goal is a desire of more dopamine in our brain. Every time you achieve a goal, you get a reward a in form of dopamine self-injection.

Unfortunately training yourself in achieving goals causes you get more dopamine b-e-f-o-r-e achieving and after that you get just only teeny-tiny injection. You feel not so good as you expected, so you want more dopamine. What you do then? Set next goal.

Desire of goals means constant staring at the difference between your current state (before ticking a goal off) and future state (after getting it done). This difference is Dis-Satisfaction.

However the delta form the structure above is called a resource needed to get the goal done, in fact this is the difference between two emotional states, two dopamine levels. This difference is felt as some discomfort.

The race form a goal to another one is driven by Dis-Satisfaction and the only way to avoid this feeling is more and more dopamine, more and more achieving.

Mindfulness

So let stop for a moment and try to see things as they are...
Mindfulness is a concept moment-by-moment awarness when you try to liberate yourself form the desire of achieving.

Following the mindfulness way you accept reality as it is and observe your relation to this reality. Obviously as human beings we need goals and we need achieve things. Starting it with awareness you achieve goals if needed, but you do it being awaken from the dopamine dream.

Hmmm...it was a little bit off-topic, but who cares...;)

DDD from a Non-Java/C# Developer Perspective

During 4Developers I met some friends who are PHP and Perl developers. They were very interested in what kind of value Domain Driven Design may bring to them.

They found the topic very confusing because in their opinion speakers were strongly focused on Java and Object-Oriented programming. Those developers made connection between DDD and OO-programing especially in Java and C#. I think it's kind of misunderstanding.

Let's see some examples of what domain expert could say (credits to Sławek):

Domain expert says:

When a piece of art is viewed as a thumbnail by a customer, one is able to show interests in this piece of by adding it to the LightBox.

The system should generate the offer from the reservation.

An offer contains just only available products with current prices.

A customer is not obliged to accept the offer. One is able to accept or reject it as well.

and so forth...

So we have some domain scenarios in a very unstructured form as were expressed by the expert.

To build the right software we model a domain base on expert knowledge and domain scenarios.

And here I wanna to put strict distinction: the goal is to model the domain but using building blocks given by DDD community is just a way to achieve this goal in the Object-Oriented world.

In my opinion pure DDD modeling should be based on Domain-Specific Languages when we have language to directly express what the expert says and how the domain works. This programing style is even easier to apply with some script and loosely typed languages.

So, if you are non Java/C#/OO professional, please be sure you may get benefits with using DDD. You don't need building blocks in the form they are currently presented, because they are implementation of DDD in Object-Oriented context. The core is to model the domain and maintain pure isolated model in a form suitable to the technology you use.

The Paraphrase Pattern

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

---

During a conversation with a stakeholder one gives you heap of chunks related to the issue. First you are unaware of language a stakeholder use, terms and their meanings and rules playing behind these elements of Ubiquitous Language. You will discover all this stuff during conversation asking right questions.

Read more about Paraphrase Pattern on http://conversation-patterns.com

PolyConf, Poznan Oct. 30-31

Yesterday I received a message from JUG mailing list that PolyConf Conference was announced.

As I mention in A Thought on Design Patterns I found a polyglotism as a reasonable way the modern software professional should follow and am glad to hear there is a conference supporting this. I am excited to see what they will present.

Diagnosing organisational problems with I-Messages

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

---

Typically conflict between people or teams is a symptom that indicates there something's up. The tool I use for that situation is based conversation patterns. With this tool you will be able to come to a bigger picture on what is really going between people.

There is very strong assumption behind this tool need to be accepted first: people are not problems on their own. A behaviour may be a problem, environment, lack of skills or even belief may be problems, but not a human being.

You-Message

In case of issues causing a conflict and lots of negative emotions people tend to express their statements in a specific way - they talk about others. Take a look on some real-life examples

• PM: Developers are always delayed
• DEV: PO must know what he really wants
• PM: The problem is team's velocity
• DEV: Requirements are not specific enough
• PO: Developers spends time on useless refactoring or something
• DEV: Business people are always changing their minds
• PM: They didn't tested all features

I have interviewed lots of people and mostly I hear same messages: He is..., They should be..., She don't... and so forth.

But what invariably surprise me most is that all of them seem to be true. Really! Spending whole day interviewing developers I came to conclusion - Damn, what the crap they deal with?. Same talking with business people I often think God, what a hopeless situation!. Every story I have heard make sense in its context.

I imagine this kind of communication something like that

The more individuals I talk to, the more chaos appears in my mind. It is really hard to understand what is going on basing on those stories.

Aha moment

Then I finally understood - all those people talked about themselves. They expressed their needs and expectations, but they do it in very indirect way. Talking with the You-Message makes other people the source of our problems and there are only two solutions in that situation: fight them or leave them.

I-Message

I followed this idea and I started using the Need Structure and Upward Generalization Pattern to lead my interlocutors to express their needs in the form of I-Message.

What are the I-Messages? These are statements where one expresses oneself, eg. I want..., I don't..., I like to..., I am lack of..., I need....

Be careful, statement I want you to stop is You-Message like not the I-one like. With I-Message you express just only yourself and nothing more, this is critical.

So, this kind of communication I imagine something like that

And some examples of transforming You- into I-.

You-Message	might mean / I-Message
Developers are always delayed	I need to close projects on time I don't want to work under time pressure I am accounted for time and budget I want to be kept informed of any problems which may cause delay as soon as possible
PO must know what he really wants	I don't fully understand what to do I need acceptance criteria for every user story I start to develop I want to be kept informed about new ideas as soon as possible I want to have an impact on the sales strategy

Notice that I-Messages express needs very clearly and it may turn out that all individuals want same thing eg. to be kept informed.

Putting people stories in the form of I-Message introduces lots of order to the communicational chaos. It's easier to see what is going on and what is needed.

Next I use Conversation Structure and Downward Specification Pattern to clarify acceptance cirteria of met needs and for negotiating the solution.

InfoQ: *-Driven* do not change anything

InfoQ Team has published my aricle *-Driven* do not change anything.

I gave a speech on these theses during the 33rd Degree Conference 2013 and I was told I didn't know Domain Driven Desing at all. Well, I have my private opinion about this. But I am sure I know how the cognitive biases work and all that *Driven* madness is one of them.

This article is not intended to criticize anybody or anything. It is about priorities and searching for a balance. Being focused on our basic skills first, helps to use a *-Driven* approach properly especially in an unknown context. I do really appreciate all those mental frameworks because they do great job. But I think if software development is driven by something, these are stakeholder needs and our common sense. Being driven by anything else might be harmful simplification.

Enjoy the article!