Coding Screen 101

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.

Top Metric Cards

Every line of code is classified into 3 categories, as explained below:

New Work

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.

 

Re-work

Re-work 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

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.

How to use this data on a regular basis?

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.

What can be a few things to watch out for?

High maintenance could be a signal for tech debt. High rework can be a signal to demand better requirements.