Coding
Last updated
Was this helpful?
Last updated
Was this helpful?
As we all may agree that engineering productivity cannot be measured by lines of code, it’s important to gain visibility into the percentage of code spent across various categories - New Work, Maintenance, and Rework.
New Work is the amount of work newly created, or in other words launching new features. Every new line of code that’s written is called New Work and this measures the innovation percentage spent by the team.
How to use this data on a regular basis?
When the business is aiming to focus on innovation, watch out this space if the efforts are being put in the right direction
Do you have a complex legacy project and delivering new features is being delayed? This metric can show you to make your strategic move.
Rework as the name suggests is working on something, and then modifying or deleting it. But, there’s a catch. Anything we build ought to be modified/deleted, but doing so within 30 days of writing the code originally is what’s classified as rework.
Why 30 days? Most agile teams have a 2 - 3 week sprint cycle and a code rewritten within 30 days can cover all possible cases of rework listed here.
What are the causes for rework?
You write it first, and then polish it for performance or ease of maintenance
Fix features based on bugs reported in QA or Prod
Deliver the feature and then learn about changing scope or requirements
Or, something works on your local, but throws errors when integrated with systems
While a certain amount of rework is normal for any team, watching out for increased rework in a given time can help address issues earlier in the process.
Maintenance or refactoring or tech debt is required for any teams and is classified as code that’s modified/deleted which was originally written prior to 30 days.
While most teams take time to work on tech debt, it’s inevitable to modify some old code while building new features. It’s helpful to watch the repos/projects causing most maintenance, monitor ROI of such projects and take up corrective actions.
What are the causes for maintenance?
Complex architecture can make building new features harder without touching old code
Update applications to newer technologies or changing business requirements
Reduce code-bloat by removing unnecessary features/code that’s not in use anymore.
The first step is to baseline the numbers for each team to see the percentage of new work, rework, maintenance and collaboration. And then, monitor for trends to see if the team’s work is reflecting your initiatives and goals.
High maintenance could be a signal for tech debt. High rework can be a signal to demand better requirements.
For a more detailed explanation on how New Work, Rework, and Maintenance work, please refer to .
Refer to know how to exclude certain PRs and commits from the calculation.
