How To Make The Best Decisions

From childhood, we are taught that in order to achieve big goals, we need to work together towards them.

Most of the time, however, what we were taught does not come into play. We may want different things, and have different goals. Or we might agree on the goal, but not on the way to get there.

Decision making is hard, and so we try different ways of making them.

From the beginning of time, until today (and unfortunately until the last human vanishes of the face of the earth), there are people who take over and decide for the silent ones. When someone decides for us, it may be easier (especially if we don’t suffer consequences). If we don’t agree, well, tough.

The old Greek tried something new, they called it democracy. There’s an equal vote for everyone, and the majority wins. If you were for it, fine. If against, well, tough again. But, as we say these days, the mechanism doesn’t scale. We can’t vote on everything all the time. There are interesting attempts to have a holacracy in some organizations (Zappos, for example), that looks for the old ways. We still need time to  learn and test it. The Romans developed the system of elected representatives. In this system, we appoint people to decide for us.

In the business world, we have more flavors. We start off with the omnipotent boss. He can decide about everything (or at least on everything important). He’s either one of the founding fathers, or was elected by the board of directors to make decisions. Promotion in most organizations are based on a mix of skills, relationship and luck. You need to be good at what you do (which may not be good enough after the promotion), you need the trust of the people who promote you, so you need to have some relationship. And luck always helps, especially when a vacancy appears.

People in managerial roles get to decide. Good managers try to do the opposite – they try to delegate most decisions downwards. The more close we get to the work, and the people who actually do it, we get more informed decisions. The higher we get (and away from the work), decisions may still be executed, but the assumptions they were based on may not be true. Execution may not align with the vision.

Let’s assume our business is moderately intelligent (and above), and therefore tries to make the best decisions. It therefore gets the best minds onboard to make them. They collaborate. investigate, discuss, and need to finally decide.

Here you’ll see that the options of decision making are fractal in nature. In some groups, a self-appointed person will try to get his agenda moving forward, he may get pushback, or defeat the weary protestors. Some groups will try to reach a unanimous consensus, which is tiring by itself. In other groups people will silently appoint others who they support. And so it goes.

Decision making is a skill

We can get better at it, by making more of them. Learning from mistakes and successes. We can also learn from observing how decisions are made in our different circles, and try to learn how to push a decision through or derail one.

We make decisions all the time. Decisions are an important part of business. So, we want to improve at them, we better start experimenting with them.

Safety is key. We won’t always make the right decision. Therefore we need to allow to fail safely.

Continuous improvement shouldn’t skip this important skill.

You want to make the best decisions?

Practice in a safe environment.

Agile Testing Days 2014–The #AgileTD Post

Second time around is even better. And much more fun. You know people, who know you. You meet new people, who want to share and talk and ask. Oh and there’s beer, more beer.

Thank you for all the people I met and re-met. You are awesome. You make ATD what it is.

It is now summary time. Let’s recap, shall we?

Keynotes this year were very good. David Evans gave an excellent talk about the “Pillars of Testing”, which continued to explain how agile and testing fit together. Antony Marcano’s “Don’t put me in a box” was an excellent show of how Antony made the role of the tester change by leading these changes (including glimpses of eXtreme Programming). Alan Richardson’s continued these lines, and bashing the term QA forever. And it was full of Transformers, Dr. Seuss, Pinky and the Brain, and Princess Bride, so what’s not to love?

Those were my favorite keynotes, and that latter two aligned with my quest this time around (not the one for beer, the other quest): What is really testing in an agile context? This is where two workshops helped. The first one by Huib Schoots about testing strategy. How does a tester approach an application? How is planning done, and what needs to be taken into account? Coming from development and developer testing background used to lead me to ad hoc testing. In system testing, a different point of view is needed, and I learned a lot from this workshop. That’s him by the way (that’s the normal situation):

Alan Richardson, Tony Bruce and Steve Green’s “Black ops testing” was also a step in the same direction – this was an actual testing dojo, where we paired on testing a web application. We could concentrate on whatever skill we wanted to improve, in a safe environment. My partner, Marine, focused on notetaking. I tried to follow in her steps, trying to learn how a tester’s mind works. I learned quite a few things, as well as tricks for creating data files for text boxes cutting off. This may sound stupid, but the ideas that you’ll need to validate text boxes for a while, and will want to speed this up, is a true quality of a professional tester. It’s a tool in her belt, just like developers carry (or may I say, should carry) TDD.

The final workshop I went too was Bryan Beecham and Mike Bowler’s “Lego TDD and Refactoring”. This was more developer oriented, although no code was written, and no Lego was hurt in the making of the workshop. If you ever get a chance to experience this, jump on it. This are Mike and Bryan:


There were quite a few genius ideas there, including explaining technical debt with Lego, and as you can see in the picture, extracting methods. Refactoring in Lego, who would have thunk?

Before there are RED blocks everywhere:

After extracting the RED method:

One more thing that resonated with me that the workshop was full. My “TDD Patterns” talk also quite filled the room. While testing is still in the title, I can see the merging of testers and developers skills continue, as slowly the distinction disappears.

What else?

George Dinwiddie’s excellent talk about the finer points in tests. He got me this TDD merit badge (plus, he has a cool wizard hat):

Marcus Ahnve talks about continuous deployment, dev-ops and wore an awesome T shirt:

Lean Coffee, which I helped facilitate  with Janet Gregory and Lisa Crispin in a crowded room. Shachar Schiff’s and Bob Marshal’s keynotes were also thought provoking, and Joe Justice’s almost sci-fi show (I called it the “I didn’t know scrum could do that” keynote). Lisa and Janet dressed up as Star Trek characters from a parallel purple universe (you had to be there):

An over-joyous #Table2 at the speakers’ dinner (which Oana Juncu can tell what actually happened). Tom Roden and Ben Williams’ version of “A Christmas Carol” (a cucumber was involved). There was a car that was built in less than a day. A Brazilian party (which was in hindsight was quite a clue about who was going to win the World Test Cup). Even I wore my costume:


Matt Heusser accepting the MIATPP award. The Agile Game night was full of learning and puzzle solving (I helped run that too with Pete George and made people feel comfortable with balloons, them picking them up):

And everyone singing along with Vagif Abilov an ABBA song as the curtain comes down.

Above all that – there are the people. Smart, nice, eager to learn and consume beer. Great intellectual fun. How much fun?

On the short, final night, I went out to Berlin with a couple of friends, and after eating a midnight Kebab, said my final rounds of goodbye to the people at the bar at 1am. As with the ATD spirit, when I came down to take my taxi to the airport, some of them were still there at 4:30am.

That’s the ATD spirit. No wonder it keeps breaking records every year – in number of attendees, quality, and events (Come on, building a car in a day? When did you last see that?)

Which brings me to the final point: The organizers.

Being currently part of a team organizing a conference (Agile Practitioners 2015, go register, it’s going to be just as awesome), it gave me a new point of view of how professional Uwe, Madeleine and Jose and their incredible team are. Last year’s was excellent, but when you start looking at the details, where the car parts were late, or working with sponsors, or just hanging with the attendees and speakers to make sure everything is fine. Everything just worked.

Madeleine told me that the trick to her job is to “make it appear as everything works”. And they have done a marvelous job again. I appreciate it even more now. Good job!

Did I mention the people already? Some of them. You can find lots of them on the #AgileTD thread. All of you: YOU ROCK!

Bye bye, Agile Testing Days, and thanks for all the beer!

TDD Patterns–Agile Testing Days 2014

Great session today (at least for me). Here are the slides.

The Illusion of Control

Why do we keep trying to attain control?

We don’t like uncertainty, and control over a piece of reality relaxes us. A controlled environment is good for our health. In fact, when we are in control we don’t need to do anything. Things work out by themselves, for our satisfaction, because we’re in control. Being in control means never having to decide, because decisions are made for us.

Decision making is hard. It’s tiring. If we get to control nirvana, it’s all smooth sailing from there.

So we remain with just a tiny problem, because the amount of control in our world is…

Slim to None

I cannot coerce people to do my willing. I can try to persuade, incentivize, cajole, bribe, threaten. In the end, what they do is their choice.

I can prepare big project plans and scream at my team to stick to it. I can give them the best tools to do their work, and they still might fail.

As managers, we can’t control our employees. As an organization, we can’t control the market. Even as a person, all I can control are my actions.

We want control, because it frees us from making decision.

Maybe we should try making decisions easier.


“You can’t have control, but you can have visibility” says my friend Lior Friedman.

When we have visibility, the fog of uncertainty fades.

Choices are clearer.

Visibility is a product of our actions. It is under our control.

As managers, we can create a safe environment where issues can appear, and we can do something about them, rather than keeping them secret until the last irresponsible moment. We can be honest with our customers to create trust between us, and improve our relationship with them, which will benefit both of us.

If we can’t have control, we should stop put effort into it, and instead, invest in visibility.

We’ll still be left with decisions. But life becomes a little less uncertain.

That’s good. For everyone, including us.

10 Reasons Why I’m Going to Agile Testing Days 2014

Just looked at my calendar, and it seemed that we’re only ten days away from Agile Testing Days! So here’s my rundown of the 10 top reasons to go to Agile Testing Days 2014:

10. Building a car in a day – This year, Team Wikispeed builds a car on-site with the crowd. Isn’t that cool?

9. MIATPP – This is the equivalent of a Eurovision song contest in the testing world. The crowd decides about the Most Influential Agile Testing Professional  Person this year. No committee, just the audience showing respect to knowledge.

8. Twitter – Last time, when the first keynote started, the audience was silent, but not online. The conversation continued throughout the conference. It’s like having your best friends near you discussing the sessions, live. Ideas and criticism flying by, and suddenly a formal presentation becomes a live shared experience.

7. Lean Coffee – This is one of the best meetings format I know, and having experienced (and cool) facilitators like Lisa Crispin and Janet Gregory helps too.

6. Organization – It’s their umpteenth time organizing conferences, so not surprisingly, the conference is organized meticulously. Jose, Uwe and Madeleine are always there, taking there of the smallest details, and I don’t know how, I’m sure they will even outdo themselves this year.  Being part of the organizing team of the Agile Practitioners 2015 team I know how hard it is, and I salute them.

5. The speakers – Some of the best minds in testing are there, and they are so accessible. There is no “speaker lounge”, because there’s public spaces where you just meet and talk. I’m so lucky to be included in such a great group.

4. New stuff – I’m still finding my through the testing world. Every time I’m learning something about testing I discover how big the world of testing is. So much to learn!

3. The crowd - What I’ve learned last time is the attendees are so eager to learn, open and kind, it’s easily one of the best conferences to mingle at.

2. Old friends – They may not be that old, true. I’m still in contact with some of the people I’ve met last year, and the social aspect of the conference comes alive. It’s the crowd’s affect.

1. It’s AWESOME! Nuff said.

Get your ticket and see you at Potsdam!

Legacy Code to Testable Code #6: Add Overload

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier.

In the last post, I’ve talked about Extract Class, and that sometimes in order to do that, we might want to change the signature of a method.

Turns out adding an overload helps in other cases as well.

We used a "setter" to expose and inject internal state before. Another option is to add a controllable overload to bypass the internal state.
Let's look at this code:
public Bool isSameStreet(String newStreet) { return newStreet == this.currentAddress.getStreet(); }

In this example, we compare an external value to an internal state. As we saw before, the option we could use is add a "setter" accessor, to allow injecting the internal value from outside. Instead, we can also add an overload:

public Bool isSameStreet(String newStreet) { return isSameStreet(newStreet, this.currentAddress.getStreet()); } public Bool isSameStreet(String newStreet, String currentStreet) { return newStreet == currentStreet(); }

We do the actual comparison on the new overload. The new overload should be accessible to the test, depending on language (so it doesn't have to be completely public). In the original method, we delegate the call to the new implementation.

The new overload is more controllable. We can stop there, but if our logic code does not rely on state anymore, why not use Extract Class?

public Bool isSameStreet(String newStreet) { return StreetValidator.areEqual(newStreet, this.currentAddress.getStreet()); }

The StreetValidator class can now be controlled and tested easily.

Time to wrap up the series. So next time, in the last chapter – using dependency injection framework.

Legacy Code to Testable Code #5: Extract Class

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier.

A few years ago I got this from Erik Talboom: "A private method is a design smell". It took me a while to fully understand it and to apply it.

There's a nice logic in there.

If at some point, we're extracting a private method from inside a public method, it probably means the public method did too much. It was long, and procedural, and probably made a number of operations. Under those circumstances, it made sense to extract some of the logic into the private method. It made sense that we could name it more clearly, as the extracted method was simpler.

It also means that the public method broke the Single Responsibility Principle. After all, we just broke it in two (at least). If that's the case, the private method we extracted contains a separate functionality from the rest of the public method.

This functionality we extracted should probably be tested. It would be easier to test, because it's smaller. If we keep it private, but called from the public method, we'd prefer not to test it directly, but through the public interface. If however we extract it to a new class, testing both will be easier, because both are simpler.

Testing and simplicity go hand in hand, and extracting into a separate class makes sense in so many cases. Too bad it's not applied often.

Here's a simple example:
public void UpdateStreet(string newStreet) { if(string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@")) { Address address = new Address(this); address.SetStreet(newStreet); } }

It makes sense to extract the validation:

public void UpdateStreet(string newStreet) { if (ValidateStreet(newStreet)) { Address address = new Address(this); address.SetStreet(newStreet); } } private bool ValidateStreet(string street) { return string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@"); }

If we keep it like that, testing the validation is problematic. Instead, we can extract the method into separate class called StreetValidator:

public void UpdateStreet(string newStreet) { if (StreetValidator.Validate(newStreet)) { Address address = new Address(this); address.SetStreet(newStreet); } }

Now we can test the Validate method, and then the original UpdateStreet method separately.

We could also expose the method as public, or make it static since it doesn't change any state. However, this may not always be the case. Sometimes in order to perform the separation, we need to actually cut the cord.

Suppose that our validation now includes comparison to the current address' street:

public void UpdateStreet(string newStreet) { if(string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@")) && currentAddress.GetStreet().CompareTo(street) == 0) { Address address = new Address(this); address.SetStreet(newStreet); } }
currentAddress is a field in our class, so it's easy to extract it into a private method:

private bool ValidateStreet(string street) { return string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@") && currentAddress.GetStreet().CompareTo(street) == 0; }
However, extracting this into separate class, requires us to pass the currentAddress as a parameter. We can do this in two steps. First, we change the signature of the method, and add a parameter with the same name as the field:

private bool ValidateStreet(string street, Address currentAddress) { return string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@") && currentAddress.GetStreet().CompareTo(street) == 0; }
Now that we “shadowed” the field, we decoupled the method from its class. The method can now be extracted to a separate class.

I find people accept extract class (if it's safe and easy) more than exposing methods, or creating accessors. The effect is the same (and the risk that someone will call it is the same), but the simplicity makes it more bearable, I guess.

Extracting a class reduces the complexity of the code and testing. Instead of the combinatorial order code paths that need testing, we lowered the test cases into linear order. Testing is not only possible, but also more probable - we are always likely to test more when the there is less to test.

That trick we did when we added the parameter? We’ll discuss it with more details next.
Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More