Fear, Courage and Unit Testing

At NDC I was fortunate to take part in a session of Cyber Dojo, run by Jon Jagger and Olve Maudal. You can have a taste at it online, but it’s better experienced with a guide. The attendees pair up, select a kata and a programming language and start adding features and tests. Every 5 minutes you switch pair. I was very lucky to pair with Michael Feathers, Jon Skeet, Corey Haines, Jim Shore and others in this session. But this post is not about name-dropping.

One thing to note is that programming was not done in an IDE. A browser-based editor for coding let you type in code, and then a single button would run the tests, and you get the result of the last run instantly.There are many things you can learn from this session (including how fast Jon Skeet could spread Linq within the different pairs Smile).

I want to concentrate on two feelings I experienced. Let’s start with…


Working without a full IDE (Visual Studio or equivalent) robs you of signals you’re accustomed to. Without squiggly red lines, warning about syntax errors, I found my self relying on the “run test” button. It was no longer just running the tests – it told me that my code also compiled, and it’s ok to continue typing. The more I added code, I used the button more - just to get feedback on the current state of my code. This feedback gave me the confidence to continue.

It makes sense – with less information, you take small steps, and try to get as much feedback as you can before proceeding. It’s like wandering blindly in a labyrinth – you feel your way slowly, try to get as much tactile data with your hands.

And on to anxiety. Even borderline…


In the last session, before the bell rung, I wandered a bit. My code wouldn’t compile, and so I wanted to get back to a safe point where all my tests ran. My automatic reaction was to press CTRL-Z to undo the last changes. And then panic struck: This isn’t a real IDE. No undo for you. I actually felt real anxiety! I barely worked from memory to make the tests pass in the last second, feeling the pressure of looming failure.

So what have I learned?

  • It’s a great experience, everyone should try it.
  • Use the best IDEs you can. Even small features make you more productive.
  • You can’t code without confidence. Unit tests give you confidence and eliminate fear.

Have you had experiences like that? What have you learned?

Is Agile Doomed?

At NDC 2011, there were a couple of presentations about the state of the agile today. Of note, were Uncle Bob Martin’s excellent “The land that Scrum forgot” (That man can give a show just by reading from index cards!) and Michael Feathers’ “The mistake at the heart of agile”.  Until the videos are out, you can get the latter’s description on Gojko Adzic’s blog.

Kent Beck’s vision, the purpose of agile, was supposed to bring developers and customers together. But something happened on the way to paradise.

According to Uncle Bob, the developers lost the lead when scrum was taken over by project managers. At the beginning, XP practices were the basis of the agile movement. But when Ken Schwaber started his scrum training courses, it was project managers, rather than developers that got the certifications. And as I’ve noted in my presentation, certifications speak the language businesses understand, and one of its keys to success.

Michael Feathers goes back further to see where the separation began. He states that It started because both XP and scrum saw the need to protect the development team within the organization. They needed to make sure that project managers, product managers and others do not rock the boat of development. The product owner in the team, is basically a gatekeeper, keeping all others outside. The abstraction kept development efficient. But it also made development less effective.

How can we overcome the division?

Uncle Bob suggests the craftsmanship movement may be the last chance to take back the ownership over the agile process, and realize Kent Beck’s vision.  Michael Feathers suggest another insight: Instead of the segregated development team, build heterogeneous teams that include not just developers, but also business specialists, support teams, etc..

Interesting stuff. While between the two, I feel more drawn to Michael’s utopic solution, both endgames seem far-fetched. I don’t see craftsmanship taking over, because business won’t let it. And as Michael suggests, re-organization of the business will be only due to business understanding that it will make it more competitive, and that requires better management. We’re a long way from there.

Is agile doomed?

Not necessarily.

In order to achieve the connection between developers and customers, more developers need to cross over to other business roles. They will be able to speak both languages: business and develop-ish. With more power and influence they can affect how organizations structure themselves, and maybe pull towards Michael’s solution.

Developers are key in realizing the agile vision. But for agile to succeed, they need to learn a second language.

So Right, So Wrong

How can something seem so right, and yet so wrong, at the same time? Easy.

When the person who speaks is different than the one listening, which is usually the case, and there’s a translation problem.

Consider the term “Refactor mercilessly”. I don’t recall when I first heard it, but it definitely caught my ear (and you know how painful that can be). You can just imagine yourself hacking your code into shape, like Edward Scissorhands. And you’re not done until everything is trimmed, there’s no excess fat, no stone left unturned, and no cliché left unused.

To use technical terms, you renamed everything in a readable fashion, you Didn’t Repeat Yourself, and your design was improved 15 times already today.

And that sounds great, like a battle cry of a professional developer. “Professionals refactor mercilessly!” (and other’s don’t).

But how does this sound to the non-technical person?

The first thing he asks is “What’s refactoring”? and you answer: “It’s changing the code without changing functionality”.

Say it out loud to just to hear how much refactoring sounds like a waste. Non-developers will never remember the second part “Refactored code makes maintaining it feasible and cheaper”.

But that’s not enough. As a true professional, you exclaim:”I refactor mercilessly!” and after you use the explanation above, the non-tech guy, who may be your manager (or future hiring manager) now looks at you funny. Maybe for the last time.

How can something seem so right, and yet so wrong, at the same time? When we don’t understand how we sound to the other side. It can also have some disastrous effect on our careers.

Want to hear more? Catch me on Friday on NDC 2011, Oslo. There’s going to be more of that.

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More