Module insights map

What is a module?

In Codigy, a module is simply a tag that you can put on a repository, folder or a file. You can add files from multiple repositories into a module. The module is associated with a domain and an owner (team). Once you map modules in your codebase, Codigy will keep track of the evolution inside of these areas. 

The mapping process can be manual or automated, learn more about this in Module Mapping.

The gist

Codigy will generate maps for each module. If a module is flagged as a hotspot in one of the overview dashboard (i.e. Domain hub) - this map is a starting point for your investigation.

This map conveniently packs activity patterns and context to give you a clear of organization design or architecture issues:

• Module changes with other modules (Coupling issue);

• Module is changed by other teams, not assigned owners (Ownership violation);

People are not good at remembering things. This map uses longer observation periods, making patterns more prominent.

Module map

Circles on the map are files. Circle size represents file size. As usual, everything is zoomable and interactive. Click on a file opens File Insights, click on features in the Change log - opens Feature Insights.

Module map filters

You can highlight different datasets based on the problem you are investigating:

1. Impact

Highlights files that were changed in the selected date range. Color intensity indicates the frequency of changes. 
- Changes of the assigned owner - blue highlight.
- Changes of other teams (not owners) - red highlight.

Owners should be aware of the changes other teams made in their modules. Especially if they haven't reviewed the PR. This also helps with decoupling and organizational design problems.

2. Confidence & CODEOWNERS (Or another external source of ownership)

These two filters highlight ownership. One is factual team experience (Confidence), another is what your organization has assigned as an owner. 

The current assigned owner is highlighted in blue, ownership of other teams will have a red highlight. Useful for ownership decisions, or if you are planning to split/merge modules.

3. Coupling with other modules

This filter does a few handy things:
- Loads a map of another module on the side;
- Lists all features that triggered coupling violations;
- Highlights files that were involved in those features, highlight intensity shows violation count. 

Files, feature branch names, PRs, team who authored these changes - all this context is a good starting point for investigation and decision-making.

Module metrics & info

Side panel has all the key metrics for evaluating overall health of the module: Cycle time, Autonomy, Ownership, Change log and Info.

Cycle time

Codigy measures the cycle time per relationship - cycle time of each team that worked with the module. You can also see the average cycle time of all features that affected the module in the selected date range.

Autonomy

A simple question. 32 Features impacted this module recently. How many of them also modified other modules?

High autonomy - is good. Means that your module architecture is well designed. Teams are able to deliver value without touching any other code.

Low module autonomy - indicates coupling. Something is off with the architecture or organization design. A list of potentially coupled modules will be provided, along with number of violations (indicates coupling strenght). Depending on the situation, fix will include refactoring a few files, or splitting (merging) modules.

Ownership

Ownership is something Codigy understands really well. So we have not one, but two measurements for it😉

1. Confidence

Measures which team has the most hands-on experience with a file, folder, repository or module. This is one for core Codigy metrics, no manual input is required.

Useful, if you are trying to determine who should be the owner, or if you want to compare owners assigned by your organization vs factual team experience.

2. External data from CODEOWNERS or package-info.yaml

Codigy ingests additional sources if they are available. This can be used to automate ownership management and initial mapping. You will also be able to identify areas where it disagrees with Confidence. 

Change log

All features that impacted the module during the selected date range are visible in this log. You can filter this list by team, access Feature insights.

Module info

Shows who is currently an assigned owner of the module. Timestamp and editor of module mapping rules is visible below.