The situational foreman

A couple of days ago, Uncle Bob Martin blogged about the foreman in software development. In it he makes some claims with regards to a role in software development that acts like a foreman on a traditional construction site. Uncle Bob claims that the foreman should be the master of having commit rights, and granting those to team members that prevailed long enough. While the idea reminded me by-and-large to the practice on some open source projects, I am not so sure whether we should start installing foremen (and forewomen) all over the place. Let’s see why.

Continue reading The situational foreman

The Curse of Refactoring

Last week I sat in a meeting with a ProductOwner, a ScrumMaster, and the Development Team. The team works on a legacy code base with about 2 million lines of code together with 13 other teams. Thus far there has been little to decouple the various components. In that meeting the topic of refactoring came up. The bottom line was that the Development Team needed to ask the ProductOwner for time to refactor their code for each story.

What a waste of your time.

Personally, I believe that if you have to ask your ProductOwner to plan in time for refactoring, the ProductOwner should stop all work on the product, and send you on a class on working effectively with legacy code if you are an internal employee. If you are an external employee, your client should fire you immediately.

Wait, what? That’s harsh? I don’t think so.

Let’s take a look at the underlying system dynamics.

Continue reading The Curse of Refactoring

The “I don’t want to” attitude

We live in a cruel world. Our profession of software development is very young compared to other fields such as banking, hotels, or carpenters. I truly believe we have taken a couple of wrong turns in our short history. In this blog entry I try to shed some light on it by some seemingly unrelated stories.

Continue reading The “I don’t want to” attitude

How do you know you’re improving?

I remember a lively discussion at DEWT 4 around self-education, and how you would know whether or not you are improving. There are lots of ways to engage with self-directed learning – in software testing, software development, leadership, and other areas surrounding this field. But with all these methods around, a single question remains: How do you know whether you’re improving with whatever technique you follow?

Continue reading How do you know you’re improving?

On Specialization

Over the past few months I have become more and more convinced about the fact that specialization in software development – which includes programming, design, architecture, and testing to me – is a terrible idea. I don’t know when this came up in the history of our craft, and I think we need to stop it – now. I also know that I am probably upsetting some folks with these statements, still I think you should critically read this blog entry, and make up your own mind about the matter.

Continue reading On Specialization

What is Agile Testing?

While I was cleaning u my bag that I carry around with on various travels, I found the following notes. They were part of my introduction for the keynote at the Agile Testing Days 2012 in Potsdam, Germany. My talk was on “adaptation and Improvisation”, drawing an analogy from the famous geek movie “The Matrix”. I wanted to keep these notes somewhere. That’s why I decided to put them up on my blog. Hope you like it. Imagine Morpheus’ and Trinitiy’s voice.

Continue reading What is Agile Testing?