Effort vs. Productivity on Software Development
Effort vs. Productivity on Software Development
What matters more, how long a software developer is working or how much they are getting done? Explore the difference between each here.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
I am sure you have heard that software developers are lazy. They don’t do much most of the time and only actually work a couple of hours over the day.
When you are in an assembly plant, for example, assembling televisions, it's an issue in that type of work if someone stops doing his task for just a couple of minutes. Those couple of minutes will mean that fewer televisions will be produced and when we convert that to money, it will raise the cost of the product.
Unfortunately, software managers want to manage software developers with this management style. The work of a software developer is not like that of assembly line workers; it’s more like a craftsman, and in all types of craft work, the ability to do a quality job will always be dependable on time and experience. The less experience someone has, the more time is required to do a quality job, and conversely, the more experience the less time is required to do a quality job. I liken it to making a sculpture. It really requires a lot of time and dedication to develop the skills to create a fine sculpture, and just as no two sculptors are alike, so there will not be two developers that will give the same results in any case.
For this reason, it is more important as managers to evaluate the results of the task as a productivity measure. If the developer does actually do his task with proper quality, it does not matter if it takes 1 hour or 1 day. Obviously, we evaluate the cost, and if we have a strict budget we cannot take more than a certain amount time, but that is the job of the manager, not the developer. The developer is presented with the problem or a task and he has to evaluate how long it will take to solve it and commit to being finished at that time. The manager’s job is to evaluate if that is viable or not based on costs and to make sure the developer fulfills his estimate.
Once upon a time, I was applying for the position of project leader, and the interviewer asked me how I plan to work. In my case, I implement processes and infrastructure, and train the developers to make everybody’s lives easier (client, owners, developers, and mine). I must admit that the person who interviewed me perfectly understood what I wanted to do and it made sense to him, but there was a problem. He realized that at one point my work was going to be very easy and minimum effort would be needed since the processes and the infrastructure would take care of most of the things, and my job after that point will be only to maintain the processes. He did not like this because in his words, “After implementing the processes you will not be working on anything most of the day.” For him, the fact that I did not have anything to do for most of the day was a problem, even though I was going to create a work team that would be 4 times more efficient and productive than the one he currently had. (He was looking for team leader because he had a sinking project).
This is the problem when effort is more valued than productivity. The managers tend to appreciate those who stay late at the office, come to work on weekends, miss their son’s birthday, come to work while his mother is at the hospital, and those who haven’t take vacations in 5 years or more. On the opposite end, they despise the ones that work from 8:00 am to 5:00 pm and leave the office on time, do more stuff in less time, and improve and get better at their work.
Productivity is everything. When you have talented developers, the challenge is to learn how to measure their work on real productivity, how fast they finish the task, how many bugs the code produces, how many times QA returns the tickets, how many times the user says this is not what I need, and so on. But not on how long they are actually busy.
Having a developer with little experience is very expensive; maybe they will be working all the time, but if he cannot deliver without failing on production, he takes long time to do things, and delivers what the client did not ask for, this becomes an expensive problem, even if you clearly see a great effort.
Of course, this does not mean that talented developers should not have discipline, nor permission to break rules and do what they want. The point of all this is to show the importance of valuing the productivity over the effort. It will be your job as a manager to find ways to keep talented people busy. You can use strategies like the ones in the book Game Frame by Aaron Dignan.
Published at DZone with permission of Alfredo Pinto . See the original article here.
Opinions expressed by DZone contributors are their own.