Wednesday, 6 July 2016

Why not estimating doesn't make sense

Here's a breakdown on my view of "not estimating" (or the hashtag #NoEstimates).

Let's start with the NoEstimates definition:

Key: "...alternatives to estimates [of time, effort, cost] for making decisions"
One could wonder why "value" or "benefit" is left out of the list, as if value alone would be enough, but anyway, this is in essence a good description why we estimate: to make (inform) decisions.

Let's continue with definitions. What does it mean "to estimate"? Let's go to the dictionary:

But, perhaps NoEstimates uses another definition? No, it doesn't seem so. This is a slide from a presentation by Woody Zuill:

Basically this definition is the same thing as the dictionary version. The dictionary is just more "condensed" and better generalized.

So, the definition would now be "...alternatives to having a general idea about the size or cost of something for making decisions" (I excluded "value").

Let's look at "size". When making decisions, those decisions have impacts. What we want to get a general idea about is the size of the impacts of those decisions. And here the NoEstimates definition of "estimate" fits as well. Everything we do has a cost and takes some effort (and has "value", but we've for some reason left that out). It's the size of those things we want to have an idea about.

Now, one automatically wonders: what would an alternative (to estimates) be?

There are alternatives: Random or chance/hope (and time traveling, but I won't cover that).

You could do "Eeny, meeny, miny, moe" or roll a die, flip a coin, JavaScript Math.random() or turn to Tarot cards, haruspicy, tasseography, or... well the possibilities are probably endless.
But if you'd make a decision (and spend money on something) would you use any of these methods? Well, some do (I guess). But as a piece of advice?

This can't be it. But other alternatives?

Setting a (fixed) budget? But what should the size of that budget be? Math.random()? And how would we have an idea of the size of the scope for that budget ("What's possible")?

Setting a timebox? Question still remains: what's the size of that timebox? Math.random() again..? And the other question remains as well: the size of the scope for what can be accomplished within the timebox?

Seriously, I can't come up with any alternatives. And I've so far never heard one either. And to be honest; there are none either. It's plain old common sense.

Hence, not estimating doesn't make sense.

Monday, 6 June 2016

5 questions before mob programming

I guess most people have already heard about "Mob programming" by now. If you haven't, there are quite a lot of sources out there. Start at Also check out this youtube video.
I both do, and have been doing, mob programming for some time now. I think it's a great way of working in some situations and contexts. Basically we have used it as follows: instead of having one or two people working on a thing and then demonstrating how it was done with a code review, we all work on it together. This is usually common when there's something more "difficult" that needs to be done or when there's something that everyone needs to have a good insight into. These sessions usually last between half a day and a day, or perhaps a couple of days (though I have never been part of that) and have involved around 3-8 people. And with these situations in mind, mob programming isn't really something new. It's the setup (how to arrange a mob programming session) that I think is something to look at. I'm not going to go into details about this setup in this post, you can find resources online. Or drop a comment and I'll try to explain.

But how would it be like to always work in a team as a "mob"? I have some questions in mind. Questions I think one should ask even when considering mob programming sessions for shorter periods of time.

1. Productivity/Cost?

To my mind, mob programming feels expensive. I have never performed any experiments to measure if/how/in what way productivity is affected. But looking at what has been accomplished during these mob programming sessions I can't say that the productivity has increased significantly. For us, this hasn't been the main purpose for doing it either. There are other benefits for shorter periods of time.
But one can just look at it purely mathematically (statistically).
If 8 people finish a task in 1 hour, that task will have cost 8 hours of work.
If 8 people finish one task each in 1 hour they will have finished 8 tasks, and each task would've cost 1 hour each.
Thus, a mob of 8 people needs to increase their productivity by 800%. OK. I hear you. Nothing is never completely parallelizable and probably 8 people might be able to get things done a bit faster. But still: 800%. Things aren't done that much faster, if any faster at all.
Software developers are expensive already. I don't think those paying us would like it to be even more expensive than it already is. So, this is really something to consider before starting; what are the other benefits of working in this setup?
Those benefits usually revolves around less or no meetings (daily standups, code reviews etc.) and also an increased knowledge sharing and overall code quality, no code merging issues, no nonprogressive items (e.g. when someone is absent). But I think there are things to consider here as well. What about training? Do we send the entire mob? Or just one or two? If so, who? Or is the mob responsible for their own training? How is that arranged? And on another (related) topic; what if the mob works on something and everyone "gets it" except one person who doesn't? Is that person comfortable with asking? Because again: productivity. Suddenly there are 7 people explaining something to 1 person. With 8 people at a halt. It might actually go faster explaining something having 7 people explaining it (more inputs/aspects), but it might just as well go even slower having 7 people talking at once. It leads me to the next question.

2. How to deal with Groupthink? (Or the opposite?)

If you haven't heard about groupthink before, you can read more at wikipedia: Groupthink. Specifically; does the mob foster too much agreement rather than surface disagreement? I have no answer to this kind of question. I haven't done mob programming long enough to have noticed any problems with this, but I would be concerned about this if working in a mob situation for longer periods of time.
My experience so far is actually the opposite. I don't know if there's a word for it (similar to "groupthink"), but I've worked in groups containing people with "strong opinions". And that is really good in a way, because it carves out great results (again: in my experience). Thus, you can say that my experience is that we actually are surfacing disagreement. But the flip side of this is that things takes even longer time to complete (see question 1) - reminder: in my experience. We haven't had a need to really deal with this, because carving out great results (and not as in quantitative results) have been the focus and purpose.

3. Rules for opting out?

What would we do if someone in the team doesn't want to mob? How do we make sure that we don't "force" this upon someone? (I guess these are relevant questions for pair programming as well). Does the whole thing collapse? Can someone be allowed to go off into a corner on his/her own? Is that OK? How will the other team members feel about this?
I have no answers to these questions. I've only been in groups where everyone really wanted to do it. Except one time. It was a team with only three members, so I don't know if it counts. But anyway, one team member didn't want to do it and we "solved" it by not doing it. We reverted back to one pair and the other developer working on things on his own.
Still, valid questions to consider before starting a mob.

4. What are people's skills and interests?

This is related to the previous question. There might be some people in the group that aren't interested in some areas of development and/or have no intention in deepening a skill in it. Perhaps some people in the group have no interest in SQL or HTML/CSS or graphic design or interaction design or the backend code or anything else. Should we force these tasks upon them? Should we split the mob into smaller mobs? Is it even still a mob then? Have we kind of lost the benefits of the mob then?
Again, this has never really been an issue for us. We have worked on very specific things for shorter periods of time. Thus, it has always been interesting for everyone to see and be part of what's done. But is it true for everything and/or in the long run?

5. What are the means for hiring more people?

If we have a mob, why would we hire new/more people? What's the purpose? And a different, but related, question: how big should the mob be? If everyone is working on the same thing anyway, why not reduce to e.g. 5 people or 4 or 3?
One reason might be that the mob is missing some kind of competence/skill. But after that? Do we have to form a complete new mob? How big should that mob be? Or should some people (with certain competence/skill) switch between two (or more) mobs? If so, is it still called a mob? Are we limiting ourselves with whom we can hire (see question 3)? Or is it better to just keep increasing the size of the mob to get increased productivity when starting/investigating/experimenting with new initiatives? Or is it better to let the existing mob switch between initiatives? But then... have we lost the ability to hire more people? What will that lead to?

Pair programming

Some of the questions actually apply to pair programming as well. Especially the first question. But with a pair you only have to increase productivity by 200%. And one could argue that the quality level increases by the same amount making the extra cost worth it in a longer perspective. Though in my experience, this is far from always true. In many projects (when I think of it, I guess it's all of them) I've been part of, the cost tends to drift away, forcing us to stop working in pairs after a while or asking for more money/time. That might be bad move in the long run (or not?). And sometimes a single developer might spend way too long time on a task not asking for help as well. And when working as a pair, we always produce more elegant solutions and it always feels very satisfying (and what's that worth?). But still, I think it's a relevant question when pairing as well: is the additional cost actually worth it? Is the quality and knowledge sharing etc. increased by the same amount? Anyway, two people is at least "only" double the cost.
Would you hire a painter where one paints while the other is standing behind giving advice? I know, it's not comparable with knowledge work. But from a cost perspective it's still relevant. Would you hire 8 painters with the same setup?

Perhaps there are more questions to ask. Feel free to add those as comments and I might add them.

Saturday, 2 April 2016

An attempt at explaining HSL colors

Working with CSS (Cascading Style Sheet), I've come to appreciate HSL (Hue, Saturation, Lightness) colors over the more common (I'd say) RGB (Red, Green, Blue) that is used when working with colors in CSS. I think it feels like a more "natural" way to think of colors. Once you get to know how it works. RGB is pretty straightforward since it's just a mix of red + green + blue, and by mixing those colors you can get different nuances. HSL is not equally straightforward. At least that's what I think :-)

HSL is part of CSS version 3 colors, but currently it seems that Internet Explorer 8 is the only of the major browsers not supporting it (see caniuse).

But why do I like HSL better than RGB? I'll try to explain how it works, and then you can judge for yourself what you think.

Just like RGB colors, HSL is represented by three values. The first value (Hue) is a number between 0 and 360). It's the number of degrees in the color circle (and thus, 0 and 360 is the same value). See this picture:
HSL color wheel
(picture from wikimedia)

HSL(0, X, X) is red. HSL(120, X, X) is in the green area, etc.

Now, let me jump to the last value - Lightness. I think it's a bit easier to explain than Hue. I think of it as "whiteness" or "blackness" (duh!). A number between 0 and 100%. Thus 100% will always be white and 0% will always be black - no matter what the other values are.
So HSL(0, X, 100%) is white just as HSL(120, X, 100%) is white. And HSL(0, X, 0%) is black, just as HSL(240, X, 0%). If you stay at 50% you'll have "medium" lightness.

HSL(0, X, 50%) is red. HSL(60, X, 50%) is yellow.

What's Saturation then? I like to think of it as "grayness" or, inverted, as "colorfulness". A value from 0 to 100%. Where 100% means "full color". And 0% means gray. And 0% will always mean gray, no matter what degree in the color circle you set. But! The Lightness value trumps this value, so HSL(X, 0%, 100%) and HSL(X, 100%, 100%) is still white and HSL(X, 0% 0%) and HSL(X, 100%, 0%) is still black. But by playing around with the Lightness value, you can get different shades of gray.

HSL(0, 0% 50%) is gray and HSL(0, 0%, 80%) is lighter gray.

And now we're starting to touch the beauty of this (at least what I think).

Let's say we have the color red: HSL(0, 100%, 50%) (remember that S:100% means "full color" or "no grayness"). If I want to have a darker red, I just decrease the lightness.

Red, HSL(0, 100%, 50%):
Darker red, HSL(0, 100%, 40%):
Add some "grayness" to make it look even darker:
Darker red with "grayness", HSL(0, 70%, 40%):
(be careful with the Lightness value, it quite quickly becomes very dark (or white), e.g HSL(0, 100%, 20%)):

Anyway. Perhaps you see what I mean when I say that I think this feels more "natural"? When playing around with nuances of colors I think it's easier to work with HSL over RGB.

Let's say I want to have a red pastel nuance. I think it's quite easy to think how I would create it. First value would be 0 degrees: Red) then I'd add some "grayness", and also make the Lightness value quite high. Let's just try with HSL(0, 80%, 80%):
And voilà! First try. I think it looks pretty good.
It's not equally obvious (in my opinion) how that would've been accomplished with RGB. I would've started with Red 255 (255 is max value (a byte, 0xff, is 255)). But then what? I know that RGB(255, 255, 255) is white. So perhaps RGB(255, 180, 180) would be similar?
Ha! That actually looks pretty good as well. Let's say I'm quite good with RGB values as well ;-) But it lacks a bit of that "grayness" I wanted to have. And... I think I know how I would've achieved that as well (just decrease the Red value a bit). But anyway, working with HSL in this way feels like I can express what I want to achieve in a better way.

Wonder what the RGB value of HSL(0, 80%, 80%) is? It's RGB(240, 170, 170). So, I was pretty close :-) And if you still prefer RGB, it's quite easy to convert. Just google for "HSL to RGB converter" or start Chrome developer tools; there you can shift+click (in the "Styles" tab) on a color to switch between the different color modes.

As an aside, there's also HSLA that just adds an extra Alpha value. 0 to 1, where 0 is transparent and 1 is opaque and 0.5 is semi-transparent.

Hope that explains how the HSL color "mode" works. At least it is how I've come to understand it :-)

Monday, 21 March 2016


Some time ago I wrote a post about the #yestimates hashtag. A quite uncontroversial post...
Lately I have thought about it. Why is it even needed? I think this tweet frames my thinking quite accurately:

(The tweet points out that the "#yestimates camp" has no wisdom (the "..."). As if we are somehow obligated to come up with our own ideas and, if we don't, we should not question things.)

It feels as if it has me down as someone who just loves estimates. I don't. I'd love to not have to estimate (although I see value in estimating. To quote Dave Gordon "the best estimates open a dialog").
#yestimates didn't even exist before there was #noestimates. In that way it's only meta. It has me down as someone promoting or defending estimates as if it even means anything.
One could also claim that #yestimates is equally binary as #noestimates. As if that means anything (see what this is doing?)

To summarize; without #noestimates there wouldn't be #yestimates. Thus, it isn't needed.