Use cases
Join our community on Discord Book a demo Login Sign up free

2024 Code analytics software | Codigy. All Rights Reserved, Codigy UAB ©

Module mapping

Everyone knows paralyzing problems that are too intimidating to start solving.

The rule of thumb is to dissect mega-problems into bite-sized tasks. That's the idea behind mapping the codebase into modules.

It's an essential step if you are looking to👇

  • Decouple your codebase;

  • Achieve high-autonomy and high-ownership for your teams;

  • Accelerate your delivery flow and reduce change-failure rate;

  • Gain visibility over what is happening in your Engineering (i.e. how team effort is distributed, what is your throughput, cycle time and ownership in each module);

When it makes sense to start mapping🤔

Pre-seed (~2-3 Engineers): Your product is probably too volatile at this stage.

Seed (1-2 Teams, ~5-10 Engineers): Your product is getting validated, and core use cases of your product become more apparent. If you start mapping now, before hiring more Engineers, you will have:

  • A better understanding of who and where you need;

  • Visibility into how to change your architecture to facilitate multiple value delivery teams;

  • A stronger cultural core and metrics to survive the chaos of rapid scaling;

Series A & beyond (Multiple teams, multiple domains, ~50-3000 Engineers): You have one or more validated products, that keep growing and splitting into services. You're aiming for a fast delivery flow, and predictable, safe releases. Mapping at this stage in an essential tool to help you with your challenges and track your progress.

What you get with Codigy module mapping:

You can use rules to tag any file or folder, inside one or more repositories. Tagged items will be perceived as a module. For each module Codigy will track it's change history.

This gives engineering leadership mission-critical visibility into:

  • Effort and ownership distribution;

  • Coupling within your codebase (Module changes are isolated, or it frequently changes with others);

  • Metric granularity (I.e. what's our cycle time, or throughput per module?);

There are three ways to do the mapping:

1. Fully automatic. If you have started modularizing your monolith or moving to microservices, you can create a rule to target a folder or a repository.

All subfolders within it, will be mapped as modules, owners will be automatically assigned based on factual ownership.

2. Semi-automatic. Codigy will generate a module for each of your teams, based on the contribution patterns. Based on an assumption that each team has a purpose, Codigy will help highlight this purpose in the codebase as well as overlap with other teams. This a good start to refining your modules.

3. Manual. You can search across your entire codebase. Visual mapping tool will help you review all results and build modules.

Have a question?

If you need a more detailed explanation about any of the Codigy metrics or mechanics - fire away in our community chat on Discord 👌

This page was last revised on January 8, 2023

Return to main


Codigy, UAB

A.Jaksto g.9 Vilnius, Lithuania

Suite 346

+370 608 96 491 hello@codi.gy

2024 Code analytics software | Codigy. All Rights Reserved, Codigy UAB ©