Most of us developers are payed really well, definitely above average, and in a most of the cases we have a very vague or even absolutely no idea of the value of the software we deliver.

No idea about the value

In some cases this value might be big and then the customer’s big investment might pay off. Unfortunately usually we are not building the right things, which on the long run results in different forms of ending the engagement; projects are abruptly cut after a couple of years of hard work, consultancy relationships cool off.

Inspired by church quotes

Yesterday (21 May 2015), Wes Higbee gave a thoughtprovoking, very interesting talk on the Software Craftsmanship New York meetup at Thoughtworks with the title Software as a means, not an end.

He is very much inspired by the quotes on the church wall across the street from his apartment, where he got the quote for yesterday’s talk as well:

Woke up

One of the cornerstones of Wes’ message is that the regular way of compensation is putting the wrong incentives in place, especially if you - do what you’re told and just “do your job” and - if you’re “payed by the hour”, i.e. like most of the regular developers we are payed based on effort

The very fact that we don’t ask questions and just burn through the customer’s resources a lot of time without knowing anything about the return on investment is disturbing and this message highly resonates with me too.

Wes drew a picture to illustrate his ethical model, in which - as he explained it, one day, just woke up to the realization - he found himself in the middle:

you lose, I win         accidentally win           we both win
                             Wes   ------> 

He realized that he is not happy with his current situation and wants his collaboration with customers to be based on value. This was not received well by his otherwise awesome boss and he started his own business, implementing his principles.

The insipiring part of the story is that HE IS SUCCESSFULLY APPLYING VALUE BASED CONTRACTS to his business.


Who are you doing business with

The key thing is to have a great relationship with the customer. Let me repeat that, as it was stressed a lot yesterday and I do think it’s key too. The key thing is to have a great relationship with the customer.

If the customer is unreasonable, not able/willing to go through the thinking process to get to the answers of these hard questions around value, then that customer is not selected for business.

##The Mountain of Why?

We tend to jump into implementation and solutionizing way too quickly, instead we should climb the Mountain of Why’s where getting to the real problem will give us actual perspective and ability to see alternative solutions.

1 to 10

Pricing your services is a key element in the discussion. The basic strategy Wes is using is estimating to some extent the alternatives, enlists the risks and go for only those projects which are producing enough business value so that 1/10th of the business value is worth for him to be payed for and that’s what he asks for. If he runs out of time and goes above, 2 to 10 or even 6 to 10 was a worthwile investment for the customer.


Wes is an energetic, successful guy, who believes in value driven business consultancy and it is definitely worth to keep an eye on him as this approach might get some real traction in the next few years.
I really enjoyed the talk he gave and he insipired my curiousity enough to put behind my concerns around the complexities of assessing value and start reading his book to discover more of his thoughts: Commitment to Value. I do believe that if this is possible in the consulting world, then we can somehow apply the same principles within a company as well and even though these will require massive organizational changes, it is a very rewarding vision to aim for.

Jepsen and InfluxDB, Chapter II. Where is InfluxDB on the CAP scale?

This is a continuation of [the hacking to get Jepsen work with InfluxDB](/distributed_systems/Hacking-up-a-testing-environment-for-jepsen...… Continue reading

How to prove that your parallel code works?

Published on December 13, 2015