Start your free trial
Book a Demo
Sign in

Software Development Metrics: The Sum of Developer Skill and Team Organization

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Run-through

May 2022 Release Notes – Issue Tracking & More

May 16, 2022 No Comments

Recent updates improve issue tracking already in the app, extended Project view, helpful Knowledge Center, and continuous improvement, adding:

* Jira / Azure Boards in the new Overview tab
* New tabs for Project
* Knowledge center
* Fixes – invitations via email, support chat

Read More »

By Gitential Team

Which software development metrics should be improved to boost your team’s performance the most? Cycle Time is the top metric to improve, but it is a composite of all other software development metrics including Velocity, Efficiency, and Utilization. These, in turn, are driven by developer skill and task complexity. How teams are organized also factors heavily into efficiency. It’s very difficult to find where one “factor” doesn’t strongly influence other factors. It’s all interconnected. Aum. Ha.

Borg is coming.

Cycle Time - “The Eye in the Sky” Metric

Cycle Time is the ultimate software development metric to improve, but it’s essentially the product of most other metrics combined. Improving almost any other metric, while maintaining the same standard of quality, will register a decrease in cycle time. Cycle Time measures how long it takes to complete a unit of work – a story point. Improving cycle time improves Lead Time and Takt Time, so it’s the one to focus on. It is your “eye in the sky” metric for how your team is improving, and probably the one that C-levels understand the most.

In Project Visibility, the severity and scope of problems in software development helps diagnose whether the “problem” is a management or developer issue. There, we highlighted what software engineering managers need to do and steps to take to correct (most) management issues.

Three Software Development Metrics to Prevent Escaped Defects, showed that when management issues were not the root cause of a problem, developer skill often was. Absent ambiguous task requirements (and startup/rapid team expansion scenarios), developer skill is a major source for excessive code complexity, code churn, and a lack of test coverage.

How to Improve Software Development Metrics?

Developer skill and software development metrics are closely associated. If not owing to ambiguous tasks and bad hair days, developer skill and experience is mostly responsible for code churn, code complexity, and test coverage. We’ve addressed ambiguous tasks. We can’t require all developers to shave their heads. So, that leaves us with improving developer skills.

Herein, we can’t just measure a new developer’s velocity or lines of code without also considering their code’s complexity and testability. And, we can’t fault code churn if it means they are reducing its complexity and increasing its testability.

A junior developer may take a full day to do what a senior developer can do in an hour. That’s normal, natural, and common across most professions. The question for software engineering managers is how do you accelerate a developer’s development?

  1. Coding standard with style guides
  2. Mentoring
  3. Code reviews with senior developers
  4. Open source resource library
  5. Assign tasks corresponding to skill level (by programming language)
  6. Transparency with software development metrics
  7. Daily stand-up “Tips of the Day”
  8. Continuing education programs

We’ve covered most of these at some length on the blog, but two deserve more attention.

Senior Developers and Mentoring

Warren Buffett mentored Bill Gates; Bill Campbell mentored Steve Jobs, Jeff Bezos, and Larry Page. Nothing is more educational than time spent with a master of the craft. Alas, that time also comes at a premium. Many companies may not be able to afford a high ratio of senior to mid-level and junior developers.

Senior developers almost always have a lot on their plate, so it’s important to balance their load.
Concurrently, all developers are not equally disposed to social engagement, even in a training context. Others… like to show off what they can do. Leastwise, it’s worth getting to know your most experienced team members, their style and preferences. Then, develop a mentoring program to maximize their impact on team development relative to workload.

  • 1-1 mentoring with a senior developer and each mentee 30-60 minutes each week during or in addition to code reviews.
  • 1-1 mentoring between senior developer and mid-level developer who in turn serves as mentor for junior developers, as above.
  • Team classes – as interest/schedule permits, can be offered as after hour meetups, on or off the clock according to company policy/approval.
  • Stand-up + Resource Library – Add 5-15 minutes to daily standups to identify good examples of open source projects as aligned to specific tasks to focus on specific elements of what makes that code good.

Though mentoring is at its best on a one to one basis, there’d be very few high school or college graduates if not for teachers with classes of 20-30+.

Open Source Resource Library

Odds are that the code your developer’s need to write has already been written – as there are millions of open source projects on GitHub alone. This isn’t meant to encourage plagiarism or copy-paste coding, suffice that there are plenty of examples junior developers can reference to help inform their logic and coding structure.

A small upfront investment by experienced team members can have a huge return on improving your team’s software development metrics. Identify and reference Open Source projects similar to your project requirements to junior developers. Draw attention to the logic, sequence, use of comments, number of parameters, nesting of elements, and naming of variables it uses.

A lot of learning comes from seeing how the task is done, and then doing it yourself, over and over again. If nothing else, this should help reduce code complexity and code churn while increasing test coverage, velocity, and efficiency. Depending on the nature of your team’s projects, it may also promote code reusability. If so, keep that code top-center in your list of library links.

Improving Utilization - Story Splitting

As utilization increases, a lot of other metrics degrade (more code churn, lower velocity). That’s especially the case when developers are dividing their attention across different projects. Excessive utilization can lead to burnout – and we want to avoid that for all developers. Burnout is most likely to impact mid-to-senior developers as more tasks fall to them.

So, this brings us back to story points and dividing tasks into small, meaningful, and logical tasks. Can high-story point tasks be logically divided into smaller, simpler tasks? In a lot of cases, yes. This warrants a look at the Story Splitting Flowchart. Yeah, it’s a little scary to look at, but if you can master story splitting – you’ve won half /“a big part” of every war you’ll ever fight in software development.

By splitting stories, you’re reducing task complexity making it easier to find examples, reducing code complexity and several other software development metrics. This, in turn, will impact your cycle time like… a six pack of Red Bull while you’re listening to Metallica’s “For Whom the Bell Tolls.” Cycle Time Marches On!

Sorry, I got a little carried away there…

At the same time, you’re reducing the load on your more experienced developers. But, as we’ve suggested previously, this may require senior developers to work more closely with Scrum Masters to breakdown and better define the tasks when adding them into Jira (or other PMS).

Improving Velocity

Velocity plays an important part in cycle time. Finishing tasks (story points) faster is the objective of velocity. Writing more code faster is not. Complex code often infers “more code.” Code is read more than it is written, so excessive code complexity suppresses all software development metrics.

Writing simpler code isn’t always faster than writing complex code. It takes some thought to create efficient code. Having less complex tasks coupled with your curated related OpenSource examples showing good structure, logic and sequence to follow makes it easier to write less complex code. Less complex code is easier and faster for everyone to read – and debug.

Improving Efficiency

You already know at least part of what I’m going to say about improving efficiency. Yes, increasing coding skills with mentoring, providing useful examples, breaking complex tasks into smaller tasks will reduce code complexity and lead to an increase in efficiency. But, there’s a lot more to the picture in terms of improving efficiency than coding factors.

Team size has a direct impact on efficiency. The Ringelmann Effect and Metcalfe’s Law help to explain why. The impact of team size is so pronounced that even the military is organized around efficient team sizes.

The Ringelmann Effect

Functionally speaking, the larger team the less productive each team member becomes. That’s the Ringelmann Effect. The drop in productivity comes from administrative overhead, complexity of communications, slack, and other effects. Here’s what the Ringelmann Effect looks like:

The average software development team has seven team members. For this, the Ringelmann Effect predicts a productivity rate that’s just 57.1% of its potential.

An often cited study by Stripe indicating software developer inefficiency averages ~ 31.6%. That’s good news, but it should be expected as conscientious software engineering managers actively engaged with DevOps are beating the norm by 11.3%. But, 31.6% is still a lot of waste.

Complexity in Communications

Metcalfe’s Law uses the formula n(n-1) / 2 to measure the inherent complexity associated with the number of possible communications channels. This doesn’t assert that every team member will need to communicate with every other team member. But it does mean that self-organizing teams will spend a lot more time self-organizing the larger they get.. for starters.

Communications Complexity

# of Team Members 2 3 4 5 6 7 8 9 11 13 15
Team on project 1 3 6 10 15 21 28 36 55 78 105

Team size introduces complexity that cascades into everything your team does, including the systems it designs and develops (see Conway’s Law).

But, times are a changin’! Adding DevOps to the Picture

If the Ringelmann Effect is so important, why should you increase the size of your teams?

This equates to DevOps for software development teams. It implies that each software development manager should be assisted by a DevOps specialist. Fortunately, the DevOps specialist doesn’t have a lot of gear to lug around and so can handle both tasks. DevOps can automate processes while targeting code and software performance issues for developers. Every team should be pushing toward Continuous Implementation → Continuous Delivery → Continuous Deployment.

Optimizing Software Development Team Size and Structure

Every project has many variables, there’s no one size-fits-all. For many companies, it may be budget. For others, availability of specific programming language expertise. Maximum effective team-size will always come down to software engineering manager skill and experience.

If we want to organize around efficient teams, we’re looking at something like:

  • Project managers – one can oversee 3-4 software development projects.
  • Business analysts – one is sufficient for 3-4 feature teams
  • Designers – more variable, but often one designer is good for 3-4 feature teams.
  • Software Engineers – one for every 3-4 feature teams.
    • Each feature team would consist of 1 team leader and 3 developers (for efficient pairing).
  • QA Specialists – also variable, as some developers are responsible for their own testing in some teams, but again, 1 QA is good for 3-4 feature teams.

This won’t work for every project, but it’s a good foundation that can be customized. Leastwise, if you’re involved in planning for a startup up, or scaling up a startup, this can be a very useful template for planning purposes. A Scrum Master is not included in this org chart, but only one should be needed for 3-4 feature teams. The more cross-functional your team members, the more efficient it will be, too.

This format is predicated upon the military’s Rule of Thirds. This advocated having one senior developer for every 3-4 mid-level developers and similarly, one mid-level developer for every 3-4 junior developers. This ratio ties nicely into mentoring and training programs and is also a key component of long-term retention planning.

About Gitential

Gitential is an Analytics and Engineering Intelligence service provider bringing visibility and optimization highlights on teams’ productivity. Our mission is to enable faster, data-driven decisions to continuously improve software delivery team cost performance and proactive risk management.

Ready to explore different ways to improve your software projects’ efficiency? Schedule a meeting and we will be happy to listen to and discuss your needs.

Have a project but are not quite ready to contact us? See if Gitential is a fit for you!

FREE TRIAL FOR LIFE
for up to 5 repos, 10 devs and 3 months of data
Register for Free Now

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Gitential.com Inc.

  • 874 Walker Rd Suite C., Dover, 19904, DE, USA
  • info@gitential.com
  • (650) 680 7697

Resources

Legal

Gitential.com Inc.

  • 874 Walker Rd Suite C., Dover, 19904, DE, USA
  • info@gitential.com
  • (650) 680 7697

Resources

Legal

Copyright © 2021 Gitential.com, Inc. All rights reserved
Twitter Facebook-f Youtube Linkedin