How to make your developers happy

How to make your developers happy

There’s no shortage of articles on how to improve software quality via process improvement. Today I want to look at things from the other side, from the software developer’s point of view. I’ve been a developer for 30+ years and still write code every day. I enjoy designing something new, and I like the challenge of debugging a problem. Debugging is pretty satisfying for me, and I’m positive that most developers feel the same way. 

We like mental challenges and problem solving; it’s what brought us into this industry, so I don’t mind someone finding bugs in my stuff. They’re almost always the result of some dependency or workflow that I didn’t consider. What drives me nuts though, is when it takes an hour to figure out the right setup to recreate a problem that I can debug and fix in 2 minutes. I’m not talking about the hard to duplicate intermittent problems and race conditions, just regular logic bugs.  The actual debugging is satisfying, figuring out the setup is not. It wastes a lot of time, and I hate wasting time. 

Time gets wasted because most bug reports are just a list of the steps; and maybe a general overview of the system state when the problem occurred. Defining bugs this way means that there will always be ambiguities in the setup, and as a result, bugs bounce back and forth between “active” and “cannot duplicate”.  I promise that we’re not being lazy by marking bugs “cannot duplicate,” we want to fix bugs, really!

How can we make things better?

To eliminate this “ping pong” of bugs, and create a better relationship between development and QA, get your team to “speak the language of test,” which means they communicate with test cases, not with descriptions.

The key to enabling this workflow is to develop a test collaboration platform that makes it easy for all stakeholders to create and run automated tests. If you give your developers an automated test that demonstrates a problem, I’m positive that you’ll get quicker fixes and have happier developers.

Further reading

Daniel Graziotin, Xiaofeng Wang, Pekka Abrahamsson: Are happy developers more productive? In: Product-Focused Software Process Improvement


Share on linkedin
Share on twitter
Share on whatsapp

Leave a Comment

Related Posts

Software quality a winning team

Software quality: Winning as a team

We have exposed a nice framework in previous posts: raw data produce metrics and indicators, and a rating model evaluates quality for each project component.

Software quality rating

Software quality rating model

In our previous post, we discussed objectives, metrics and indicators, as powerful concepts to finely assess multiple aspects of software quality (SQ).Using new concepts to

Illuminating system integration

Illuminating system integration

System integration no matter the approach; modular, big bang, regressive, controlled or adhoc can often be one of the most critical phases of a project.

Hey there!

Subscribe and get an email every time we’ve got a new quality piece on here.