Does the software industry have a good understanding of what impacts developer productivity? What are some common misconceptions when it comes to factors that help or hurt productivity on dev teams?
Sort By:
Oldest
SVP Technology in Insurance (except health)16 days ago
Two points I'd like to bring up: First, you can't look at developer productivity evenly across all team members. Senior engineers, for instance, spend more time mentoring and doing architecture work compared to junior engineers, so their pull requests won't be the same. Second, the evolution of software development has shifted from story points to measuring business functionality and speed to market. The ultimate goal is to quantify the speed to market as a total team effort, which includes technology, product, and other factors. It's not just about individual developers writing code, but about what the team is bringing to market.VP of Engineering16 days ago
In my experience, the missing piece is the end-to-end process. This includes understanding where requirements come from, typically business people or product owners, and how they go through discovery or design before reaching developers. Even in advanced agile organizations, there's still some waterfall methodology happening, which impacts productivity. There's no common understanding of productivity, and it's often about hours of output and lines of code. Another misconception is thinking tools like GitHub Copilot can improve productivity by a certain percentage without considering the overall outcome. This is a significant gap that needs to be addressed.CTO in Banking16 days ago
I believe the industry is still coming to terms with how productivity is measured, and there are quite a few misconceptions, not helped by some of the big consultancies out there. One of the biggest misconceptions is measuring the worker rather than measuring the work. The best way to think about this is through three pillars: input, output, and outcome. People often think about inputs as time spent working and outputs as lines of code or classes. However, these are not necessarily useful measures. It's more important to think about outcomes and value. While capturing this can be complex, shifting the mindset towards outcomes is crucial.VP of Engineering16 days ago
In my opinion, the software industry is still figuring out what truly impacts developer productivity. Often, we focus on metrics like the number of lines of code or the number of commits a developer has made. However, these metrics don't always tell the full story. One common misconception is that more output means more productivity. Factors like how well the team works together, the work-life balance of the teammates, and having clear goals can have a much bigger impact on productivity.Strategic Banking IT advisor in Banking13 days ago
Personally, I'm really concerned about the overall productivity level we are experiencing in my organization.Back in the good old days, we used to benchmark ourself with others using a specialized firm. They were using "function points" metrics. It gives a starting point for internal discussions regarding how we could become more efficient.
20 some years later, this practice sounds prehistoric. However, it never cost so much to develop functionalities in applications than today.
How come? We specialized people a lot. A typical project, 20 years ago, required 10 or 15 people. That was it. Now, it's probably 25-30 people. A ton of architects (infrastructure, cloud, security, cap&perf, data, etc.), product owner, system analysts, Q&A specialists, etc. And then, 2 developers ;-)
The pure cost of programming 1 line of code has probably remained the same. But the collaboration of so many other specialists increase the duration and the costs.
This is even true for Agile project! We're far from an autonomous squad doing CICD kind of work!
Does this sound familar with some of you?