“7 Steps for writing your first test” Slides

Here are the slides from my Sela Developer Practices 2013 talk:

 

PS: If you were not one of the thousands in attendance, I’m doing it as a Typemock webinar, Thursday May 9th. Register here.

May 7th, 2013

Tomorrow I’ve got a full day.

In the morning, I’m giving a talk at the Sela Developer Practice. This is going to be about “7 steps to writing your first unit test”.

Following that, I’m going to hang out at the Typemock booth at Agile Israel 2013.

If you’re there, come and say hi.

If not, well, I’ll catch you later.

I Have An Idea!

The biggest waste in software is what we build and isn’t used. Since we can’t know in advance what will be a selling feature, we have to implement the feature, put it in the wild, and hope for the best.

Wait, there’s more: Remember that everything we code comes with a maintenance cost, so it may be that we build something that instead of helping us make money, can even lose money. A lot over time.

To put it bluntly, that doesn’t sound like a smart strategy, right?

I like the lean startup idea of experimenting. With a low-cost experiment we can learn before implementing a whole feature if it’s worth it, or at least get a sense of success. So I’ve began an experiment on experimenting.

After thinking long about it (almost 2 minutes!) I decided to call it the “I have an idea” form. Ideas for features vary in size, and sometimes it’s a big effort in implementation. So before I’m going full force with implementing, I need to test the waters. By forcing myself to put this in words, I can really see if it’s worth it at all, or how we can build an experiment to see if that works.

The form (Word template) has two parts: Hypothesis and Experiment

In the Hypothesis part, we describe the feature from a customer point of view:

• What is the idea?
• Whom does it help?
• What does it solve?

In the Experiment part, we describe how we can learn if our hypothesis has merit:

• What are we going to do?
• Who are we going to show it to?
• How are we going to measure it?
• How much is going to cost us?
• How will we know if it succeeded?

That’s it. Pretty simple process to signal me if I’ve given something enough thought.

Will it work?

I’ll let you know.

PS. If you look closely, it’s just not for features.

Processes and Tools Over Individuals and Interactions

When I was a developer, I couldn’t understand why other developers were not as competent as me.

When I was a team leader, I couldn’t understand why my team didn’t measure up to my glorified project saving success.

When I joined Typemock, I couldn’t understand why most developers are prepared to live in bug-world, rather than just unit test.

War never changes…

During my first years at Typemock, I decided not to enter the “Typemock is too powerful” debate. The main argument was that tool capabilities put constraints on the developer. With more restrictions (that coincide with some good design principles), developers will not be able to abuse the tool. We looked at it as flexibility for any design. It was a religious debate, and as these go they were tiring.

When I first read the discussion around giving the same mocking abilities to FakeItEasy, it looked like the same debate, only with different actors.

This time, though, something felt different. I couldn’t put a finger on it at first. But what Igal (@hmemcpy) said connected with other things I heard from other Typemock alumni that went into the wild (in addition to the other regular voices): We don’t trust developers to do what we (or our boss) hired them to do. Developers, who are not skilled enough, will harm our way of life: Our code base, our practices. Where it really hurts.

The thought that having a tool will drive developers to better design is absurd. I’ve got examples aplenty. But it’s even worse: we’ve started thinking in terms of damage control. It’s no longer “with great power, comes great responsibility”. It’s “in straight jacket they can’t do much harm”. (And it’s always “they”, isn’t it?)

I was there before. I saw what unskilled people did as acts of stupidity. I was angry. I put constraints in place so “they” wouldn’t hurt “the team’s” progress.

It’s really not about tools

It’s about “us” saving the project in spite of “them”.

We think it’s the only way, since we know better. So we tie their hands. This leaves no hope for “them”, so they leave. We’d like to get more people like us, but come on, what are the chances?

The economics of the situation are simple – if you leverage the people you have, your chances of success are much better than searching for super-heroes.

But we’d rather take shortcuts. It feels we’re saving the ship. In fact we’re taking in more load.

“Individuals and interactions over processes and tools”

If you’re not willing to invest in your people, tools surely won’t save you.

The Better Side Of Anger

It was the nth time that a supplier has failed us. If we analyze it logically, there were two options: Get mad or roll with the punches.

Since we’re not Vulcan, it’s not really a logical choice: what we felt is anger, defeat. Or both.

Can’t do much with defeat. But anger is totally different.

From childhood, we’re taught that anger is a “negative emotion”. It’s counter productive. It’s not effective.

That’s a lie.

First thing, we can’t control feeling anger more than we can control feeling happy. Emotions are emotions and cannot be controlled. What maybe ineffective is our behavior based on these emotions. And we are fully able to control behavior. So maybe it’s not effective to stand in the room full of people, shout in anger at your boss, threatening to quit. (Tried it, jury’s still out about how effective it really was).

Because anger is “bad”, we don’t talk about how anger opens the door to innovation and creativity. When you’re pissed, you’re starting to think about other options. What you can do differently.

So we can replace that supplier. We can readjust our work with them. Or divert money we spend to do stuff ourselves.

We can try something else that we didn’t think was possible, because what happened until now was acceptable. Just the way it is.

Few years ago, I got angry that another  build was thrown back to the development by the testers. We’ve introduced smoke tests. We changed the way worked because we were angry. (Ok, I got angry).

Anger is not a negative emotion. Don’t be afraid of it. Don’t contain it.

What you do with it maybe life-changing.

The Real Enemy

Lior Friedman asked whether a tester should know how to program or become obsolete. Lanette Creamer said the same fate awaits programmers who can’t test.

This kind of discussion only happens in the dark corner of the software world. Within our small community.

In most companies, nobody thinks about this.

Human Resources

“When we hire a tester, make sure he does only that. God knows we don’t want to pay him like a real programmer.”

“When we hire a programmer, we don’t want her to spend her time testing, that would be a waste.”

Companies still hire to fill positions. Programmers have a very different job description than testers.  Job descriptions, however,  don’t help with fulfilling the business’ mission.  

It starts with hiring, but doesn’t stop there. Let’s say this company is one that really believes in “our employees are our most valuable assets”. How does it train its employees? Of course, programmers are encouraged to learn more programming and debugging techniques. Testers are trained in deeper testing methodologies.

Changing Roles

The agile manifesto talks about collaboration and interaction. Scrum talks about the team. Neither talked about testing and programming roles.

Extreme programming, you say? Doesn’t mention roles. But does talk about programming and testing.

The reason there’s no squabbling over roles in agile land is that role separation is really none of the business’ business. Agile methodologies are about making the business money by building quality software fast. All the process you need is already there, anything else just puts wasteful constraints on the system.

Software needs to be of high quality. For that it needs to be programmed and tested. It doesn’t really say who does what. Make it so.

And yet we’re still attached to these titles. Asking if programmers can test, or tester can program is reinforcing titles over skills.

What we’re actually doing is reinforcing HR’s role in the organization.

We’re All Developers Here

Programmers should know how to test their code. Without testing they are going to waste both theirs and the company’s time on bugs.

Testers need to program. Without automation, they are going to waste both theirs and the company’s time on manual rote work.

We all value working software over comprehensive job descriptions.

We’re all software developers.

Who hate HR.

Skillz

Everyone has skills.

According to the dictionary, here’s the definition of Skill: The ability to use one's knowledge effectively and readily in execution or performance.

In other words: ability to do something. Some will say: ability to do something well.

In a tweet a while ago, Jim Grenning defined the 3 skills of refactoring:

• Recognize bad code
• Envision a better design
• Incrementally transform bad into better, keep test passing

Ok, that’s four, but regardless, that’s a great definition. And he managed to put all that into one tweet!

Obviously, all those are skills, since they define the ability to do something.

But read them again: Not just abilities. They are higher abilities of great programmers. It doesn’t apply to most of us:

• Not every programmer can recognize bad code. Although every programmer can write bad code.
• Envision a better design? A different design maybe, but to envision a better one, you need to have skill #1, and then understand how it can be improved.
• To do the improvements incrementally requires not just the discipline, which not many of us have. It requires to envision the steps (skill #2), when most of us (sometimes) see the next step.

The good news? While not every programmer does this today, everyone can get there.

To me, skill is not just the ability. It’s the journey to achieve the higher level.

Anyone can improve their skills. The road is long, hard and full of learning, but everyone can get there. Most programmers don’t, by the way.

Decide to take the learning path. For example:

• Look at you code critically. Will you understand it in a year’s time?
• Once you’ve got the code working the first time, throw it away. Rewrite it better.
• And write tests. Lots. It’s a skill too, you’ll get better.

Skillz. Jim Grenning has them.

You can too.