What Makes Developers Professional?

A couple of posts I read lately made me think. Again.

The first one is Elisabeth Hendrickson’s on whether testers should write code. Elisabeth focuses on the perception of the tester in agile team. From Elisabeth’s research it shows that testers in teams (not only agile) are expected to be able to code. The research does not conclude what “coding” means, but some of it points to test automation. This makes sense to me, as I don’t see the developer/tester border getting blurred – the professional developer’s core skills are different than the professional tester.

The second article, Larry Obrien’s in SDTimes is a review of Pex and Moles. One thing Larry mentions: “testing cannot be palmed off to non-developers”. He talks about giving the Pex software liberty to write tests, which give the developer an impression that the code is covered by tests, which realistically are not good tests. (This is not a Pex bash, I’m saving this to other posts).

The underlying theme I get from both articles is professionalism.

Professional developers do not rely on testers to write tests for them. It’s pushing responsibility away, and that’s not professionals do.

Professional developers write great tests. It’s their responsibility, and part of their core skills. They do not rely on software generating tests for them. Unfortunately, we’re not there yet. Professional developers use the best tools to get them as much as possible on the way, but they need to complete the run themselves.

Before I tell you what I think, do you thinl professionalism == craftsmanship?

Gil Zilberfeld

Unit Testing Is Spooky!

I had a discussion today about the name “unit testing”, and its connotations.

I’d like to remind you, dear reader, that the audience of this blog is already aware of the goodness that comes with unit testing. Unit testing is part of our day-to-day work, and also for people just starting to get interested in becoming professionals.

But what about those poor souls that don’t know what “unit testing” is? Does the term sound frightening to them? When you ask your developer friend: “Have you heard about unit testing?” you probably expect: “No – tell me more about it!”

Only she thinks: “Well, I’m a developer, not a tester”. Or maybe she’s thinking: “Man, this guy is condescending. He’s using a name-of- the-week from the garbage-can of tech-talk. I’m going back to work”. Case closed, your friend now won’t even hear about the happiness that goes along with the name.

The way we talk about our favorite methodology, though we mean good, can have some horrendous results. For your friend, you either wasted her time, or wrecked a relationship.

Is it just the name?

Names of features, products, methodologies, and even people can actually create or lower barriers to acceptance. The term “unit testing” is ancient (in development years) but apparently doesn’t take into account any emotional or even cultural context. It conveys the practice, not the value it brings.

Ok, let’s rename it!

It could help somewhat (if you can now re-educate thousands of developers worldwide –they probably won’t let go of what they’ve mastered so quickly). But I don’t believe just changing the name will change behavior.

When I explain unit testing, I start at the pain: bugs. Stupid bugz. Returning bugs. Let me clue you in – developers are creatures of ego. We care about what we do, and any bug found is a dent in our armor. Bugs drive us nuts. And we’re ready to invest some time (minimum, if possible) in making sure our face-time with QA is limited.

(QA people – I love you, you know that. Don’t take it the wrong way, but in the development story, we shoot the messenger, the one who found the bug).

So when you come to persuade, use the right context and language and talk to the heart. You’ll get better acceptance, and probably take away the effect of the name.

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