03 Apr 2013 , tagged: Productivity, Happiness, Software Development
On Developer Happiness and Productivity
I’ve had the idea for this blog post in my mind for a long time. It is based on all my personal experiences and observations over the past years and is in no way scientific. It is my personal opinion, and even though this is how I perceive the world, it might not be true for other people. With that said, let’s jump to the core of things.
A happy developer is a productive developer.
While this is not particularly surprising, the reverse of this statement is more interesting:
An unhappy developer is not productive.
This might be not particularly surprising either, however, based on my observations in the past years, I was suprised how much a developer’s happiness impacts his/her productivity. I’ve seen excellent developers thrive in projects, writing tremendous amounts of quality code, I’ve seen mediocre programmers writing a good amount good code. But on the other hand, I’ve seen the same excellent developers drop to a few, forced and mediocrely written lines of code a day in other projects.
All this kind of shook my perception of what I thought made a software development team successful. Or fail. I always thought that the skills and profiency of developers would be the broad foundation for a project’s success. I thought if you had good developers, all the other factors wouldn’t matter that much. I thought that project management, tooling, the actual work, or the communication were secondary to the skills of the developers.
Boy, was I wrong.
As I’ve painfully had to learn, developer’s skills contribute only a small portion to the success of a project. As it turns out, developer’s skills can be almost nullified by a badly run project. In any non-trivial software development project, the aforementioned aspects of a project are crucial to a projects success.
If project management is micromanaging, doesn’t understand how developers work, how software development works in general, or doesn’t see itself as a supporting role to help development get their work done, your project is in danger.
If your team is forced to use inadequate tooling, forced specific tooling (“you have to use XYZ”), limited tooling (like limited number of licenses for crucial tools), or or inapropriately set up tools, your project is in danger.
If your team is just doing brainless chores, gets ignored in planning the next steps, has to use an overly complicated or convoluted process, or is forced to do what it thinks is the wrong way, your project is in danger.
If communication between the development team and other disciplines is slow, ineffective, biased, imprecise for whatever reason, your project is in danger.
The surprising part is that all these symptoms usually come as one big, painful mess and leads to a viciuos circle. Because developers have to do mindless chores, they lose interest in doing good work. Becuase they lose interest to do good work, they don’t even try to change how things work. If they don’t try to change how things work, the project ends up collecting lots and lots of technical debt. And because it accumulates technical debt, nobody wants to work on it. Because nobody wants to work on it, people leave or burn out.
In order to “fix” any of the symptoms, you need highly motivated people, but these are usually the first ones that burn out because they despair over the process, the tooling, or other aspects. The end result is a highly toxic project environment full of naysayers, that kills motivation, productivity and quality. Everybody who gets thrown in this will probably burn out or quit.
If you notice any of the above symptoms in your project, you should quit and find a new job. If you are in charge of the project, you’ll want to pull the handbrake and radically restructure your team, or the project will fail tragically.
With my past experiences I’ve been thinking a lot about how to make software development projects successful. And I feel there’s many many ways to make your developers happy. Happy developers are productive. At the end of the day it’s not hard:
- Make sure you listen to your developers. If your developers tell you they are bored by their work, frustrated with tools or process, that’s a warning sign. Work with them to find a solution to their problems.
- Give your developers a chance to change things. If developers notice that the current process is too complicated and could be streamlined, put them in a room with the project managers. They’ll be happy to improve the process.
- Educate your project managers about how software development works and how to deal with developers.
All in all, I hope that these observations will help somebody to make the right decision. And, I would love to hear back from you what you think.