Developer Productivity: getting the most out of new hires

Developer Productivity: getting the most out of new hires

“If we double the team size, we’ll go twice as fast, right?”
If this sounds familiar, you’re not alone. Every day, organizations must make decisions to help them move faster and keep up with their competition. Software development isn’t a linear process that can be easily augmented like assembly lines. Unfortunately, many companies still make decisions using traditional management styles and techniques. Instead, the software industry must employ new ways of thinking that understand the problem-solving aspect of software development and apply new technologies to empower developers and enable them to do their best work.

New projects are fun!

New projects are usually easier to work on for developers. Starting with a single line of code and building from there provides several distinct advantages:

  • Code is easy to read (you probably wrote it or know who did).
  • The codebase is smaller and therefore more manageable. It’s possible to know the entire codebase.

At this point the business thinks their dev team is made up of a bunch of rock stars!

A growing problem

However, as the company grows, so does the codebase. As the customer base grows, so do user requests for features and enhancements. New requirements, features and bugfixes naturally accumulate, and the project becomes more complicated. This complexity produces more work for the developers. The demands on the development team increase until someone has the great idea, “We need more developers to keep up with demand!”

A Typical Business Response (and temporary solution):

To manage increased demand for enhancements and deal with bugfixes, the team hires new developers. It’s a great idea: the extra capacity allows the team to take on additional work.

With more headcount, individual developers can specialize, and focus on, specific application areas. Teams are built to divide and conquer the influx deluge. Developer productivity increases cause the business to think the danger was averted. 
Wash. Rinse. Repeat. 

Sketch of the law of unintended consequences by Jono Hey
By Jono Hey, Sketchplanations:

The inevitable outcome: I got 99 problems and all of them is code

Most teams don’t acknowledge that adding more developers also has drawbacks.

With increased team specialization, fewer and fewer developers know the entire application. Eventually, no one does, and it becomes large enough that no one person could know the entire application. Specialization also leads to chained development, requiring developers to wait for another dev to finish their work before they can complete theirs.

Increased complexity requires more unit testing. More unit testing requires more time before code merges. Merge reviews take longer due to increased code complexity. Production deployments become more and more risky, requiring delicate coordination between multiple teams.

How many times has your commit made it to production only for a blame ticket to subsequently land on you? How many times does a buggy commit make it to production even though it passed unit testing?

The outcome? The same developers previously praised as rock stars are now villainized for “getting us into this mess.” 

Recognize the REAL problem

To the organization, the apparent problem is that the development team became too slow.  However, this was a symptom of the problem, not the cause! Organizations often focus on a symptom thinking it is the root case, when it’s really an indicator of other problems. There are two competing issues here. Identifying which one contributes the most is crucial:
The codebase is becoming more difficult to work on because it is growing in size and complexity.

This is a foundational issue.

The demands on the development team are growing due to increased user feedback and feature requests.
This is an appearance issue. Non-developers think the developer team isn’t moving as fast as it once did. There is a provoked sense of urgency for each request.

Here’s a novel idea: react to the root cause

As stated earlier, software development isn’t an assembly line, though team expansion can make it feel like one. Development is an intellectual task of problem solving and execution. Process enhancements alone won’t increase developer productivity or output. Developers must be empowered to do their best work and optimized as individual contributors. Continuing to add team members further reduces the efficiency of your current team members and brings new devs into an environment that doesn’t empower them.

The problem is one of managing code complexity, not burgeoning numbers of developers.

So how does one manage complex code? Enter software Intelligence, a concept enabling organizations to empower development managers and developers. Developer teams using software intelligence optimize the development process by being able to: 

  • Understand the code quickly and with greater certainty
  • Understand downstream impacts
  • Plan and estimate work quickly and easily
  • Recognize when complexity and tech debt are inhibitors and require remediation
  • Answer their questions from a single resource by enabling senior devs to demonstrate global impact to junior developers 

Interested in how continuous software intelligence can help you simplify complex applications? Read 5 Ways a Dependency Map Improves Software Development.

Learn more about Continuous Software Intelligence
Scroll to Top