collapse Members

collapse Network Default Links

collapse Most Popular Tags

The Modern Way to Manage Test Projects

Thursday, July 24, 2008 Subscribe this network's blog

Start Topics

Move, move.

I think we could start some topics in the Forum about the testing management.

I already started one: http://project.testcommon.com/forum_messages.php?mid=1&ccid=121

Interesting Posting from Testearly.com

Here is an interesting posting from testearly.com a blog by the Stelligent Agile Consulting Company

Fire your best peoplereward the lazy ones

In my experience, what most people consider to be their best people are often the root of most problems. It's the difference between troubleshooters and troublepreventers.

Let me explain

Bill Lumbergh

Bill is a troubleshooter (only). Many consider Bill to be the best employee in the company because he solves almost any problem that comes into the door. However, unbeknownst to many (especially management), Bill is the one causing most of the problems. Bill knows the purpose of every hard-coded lookup value and is the fastest to manually deploy the application to WebLogic using its web console. For instance, he knows that 14 means a transaction that is waiting for approval by second-line management. However, instead of creating a human-readable constant, Bill hard codes the number 14 in the source code. Therefore, Bill is the only one that can easily maintain these methods. In my personal experience, someone like Bill doesn't do this for nefarious reasons, he's just not thinking about how the next developer may need to maintain it. For every time a method is written, it's read (and maintained) ten times (10:1). Therefore, people like Bill need to be writing source code for other humans, not the computer.

Let's have a look at Peter

Peter

Peter is a lazy developer (a troublepreventer). Because Peter is lazy, he hates doing the same thing twice, so he generalizes common functionality into a delegating class, creates interfaces for implementing classes to adhere to, or he writes build scripts that compile, integrate the database, runs tests and inspections, and deploys the software the same way every time. Peter finds it mind-numbing to repeat himself. Again, Peter is lazy so he doesn't mind spending two hours automating something that normally takes 10 minutes to run manually. Why? Because, he very quickly reaps the benefits of this extra effort since every time the process is run he gets those 10 minutes back and even more importantly, he eliminates the possibility of human error (which, again, saves time and money).

The (lazy) troublepreventer thinks ahead. He extracts variable information into common properties files, seeks to reduce complex code, and automates repetitive, error-prone activities such as the build and deployment processes. He also ensures that others can very easily repeat what he has done. Anyone that has worked with me for even a day knows that I often sound like a broken record when I say Is it in Subversion? or Have you updated the Wiki? To me, if the knowledge is locked in your head, you are a less valuable, not more valuable, resource. Troublepreventers put their knowledge in the system, not just their heads, so that it runs the same way every time.

People like troubleshooters because they can solve a problem when a project is under pressure such as getting that emergency fix out the door immediately. Without question, you need troubleshooters on your project. However, many times the (exclusive) troubleshooters are the ones that cause the problem in the first place, be it a hard-coded value, duplication of code or a large complex method only they can understand.

Before you start thinking that I'm trying to gather together a group of slackers, I'm suggesting the complete opposite of this. I just want people to think about the total time involved, not just fixing the symptom. There are people that are both troublepreventers and troubleshooters. These are the people you want to keep and reward. However, on a given team, I'd opt for more troublepreventers than troubleshooters as they save everyone time, money and headaches.

Welcome to the Test Project Management Network

Welcome to the general group under the Test Project Management network. Here you will find general information about testing certifications as well as other members who share your interest in this topic.

collapse Newest Groups

collapse Network Statistics