The kind of work the developer does is like that of a craftsman, but a usual management mistake is trying to manage the developers like they are in a factory assembling televisions for 8 hours. In those positions, it makes sense to not allow a worker to stop doing their job because then he stops finishing the product, which translates to fewer pieces produced by day, which raises cost and lowers profit.
But that way of management doesn’t work with software developers. The software developers are usually spending 90% of their time figuring out how to solve a problem and 10% writing code. Often, managers with no coding experience think they are doing nothing during that 90% of the time.
I used to be in charge of a developer at a client’s offices on-site and the client complained a lot because, in his own words, “the developer spent most of the day doing nothing.” But when I have on-site developers I always review the daily productivity and he was doing a great job, but the client wanted to always see him writing code during that 8 hours.
In software development, our main tool is our minds. Sometimes it is clouded and makes difficult to do any job, sometimes it’s sharp and we do the work of the entire week in one day, sometimes it’s worried with domestic problems, and at other times it can really focus on the task. Realistically, a software developer is not productive beyond 6 working hours. They needs a lot of coffee (usually), and some free time to get distracted doing something else so we can be productive. Sometimes we are very stuck on what we try to accomplish and we need to talk to a rubber duck to solve the problem.
So, being a software developer is quite complicated. The problem is that the developers’ skills are unique amongst them. Some developers are more proficient in some languages, others on some database engines, others on front end, others in the backend, others on the development tools. So this complicates a lot, trying to unify the way to measure their work.
The work and problems that the developers need to solve also don’t help, as every software requirement is unique. Very rarely and only after many years of experience do we need to solve the same problem twice. So there is not a quick way or shortcuts to developing software. We can take advantage of libraries and frameworks to better deal with the technical part, but implementing business rules on software development is the hardest thing to do. Enterprise software is the hardest software to write.
But this doesn’t mean that you cannot do anything about it. It means that you need to understand the developers, walk in their shoes, so you can create more appropriate ways to work with and a good strategy.
The way that I usually deal with this is by assigning tasks to a software developer that don’t last more than half a workday (4 hours) or more than 2 days (16 hours). If a task seems to be taking more than 2 days, I will break it in two or three pieces or as many as is needed so it will not have a large task where time easily can be wasted.
For example, if a developer needs to do a CRUD, usually the simple ones take about 1 day (8 hours), so I will assign to him 1 task for 8 hours. But let’s say the create part has very complicated business rules and the update part has a different set of business rules which it seems will take 5 days to complete the job. Instead of assigning him one task with the CRUD requirement, I will break it into pieces, like1 task (8 hours) for the data grid, 1 task (16 hours) for the insert, and 1 task (16 hours) for the update. After breaking the main task into 3 tasks, you assign to him 1 task at a time and don’t let him to work on the other two tasks until he finish the first one and so on.
So if by 1 day he doesn’t finish at least 1 task, you will know immediately that something is wrong, he is wasting time or is been blocked by something and is not asking for help. I hope you get the idea. At the end of the day you need to do your homework as a manager, review what is been done and completed on a daily basis.
There is no such thing in software development as x% completed. It’s very common that somebody will tell you, “I spend 4 days in a task and it’s 90% completed, and then I spend other 4 days completing the last 10%.” It is very misleading and arbitrary trying to give task status by percents, as they will be always wrong. The only true way to measure a task is if they are completed or not.
A task will not be finished until a tester or the client (UAT) says the application works as expected, not when the developer says it is done. When the developer says it is done we just put the task timer on pause, and if the tester or the client says it is not right, the time for that task resumes running. On the other hand, if the software does what is expected when we stop the timer and then the task is complete.