Whitepaper
We can't effectively protect our software products from being copied by competitors. The only thing that can provide safety for our business is speed.
If we understand the market needs and deliver solutions ahead of the competitors, we win the best spot on the market.
Hiring more engineers to pick up the pace is common practice, but as we all know going from 10 engineers to 100 doesn't give us a 10x increase in speed. This is exactly the inefficiency we are solving.
Codigy can help make your codebase & teams autonomous, for faster, safer delivery flow. Below are the guiding principles behind Codigy analysis👇
If we want to achieve a fast workflow we have to respect the limitations of our cognitive abilities and keep all elements of work on a "human scale".
What does this mean in practice?
Small files - ideally, files should "fit in your head", and have a single purpose of existence, a single owner (person or a team).
Small PRs - it's easy to get lost if you need to review tens of files and hundreds of lines of code. If PR is hard to review, the chances of defects slipping through increases.
Small tasks - if something takes weeks to finish, it should have been divided into smaller chunks. It's much easier to align and provide guidance when we have more frequent deliverables & reviews.
The result we are aiming to achieve:
Autonomous teams, who can plan, work & release independently.
Each autonomous team owns a specific business functionality.
Conway's Law asserts that organizations are constrained to produce application designs which are copies of their communication structures. This often leads to unintended friction points.
The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture.
In simple terms, we are aiming for:
Business structure = Team structure = Codebase architecture
Consider two radically different ways of organizing teams who work on a cross-platform store👇
In such an organization, updating a marketplace experience will inevitably be slower as all 5 teams will need to sync, and handoff work to one another. Handoff is usually the part where teams lose the most time.
The second case is based on cross-functional teams. This ensures faster and smoother product updates as they are within the responsibility of a single team.
Clear-cutting your codebase into business modules is not an intuitive process. We use interaction patterns to help you validate different assumptions and achieve full autonomy👇
Two cases of how teams could be using the codebase. In both cases, we are looking at two engineers, each is working within respective feature branch. Files used in a feature branch are highlighted in color 👇
Case 1 is an ideal example. With all the contextual information we can validate that:
Both engineers are working on modules their team owns;
Each has practical experience in this area;
To complete a task, files of a single module were used;
They make small changes in a few files;
Their activity doesn't overlap;
Files used are not too large or complex.
So this is as fast and risk-free as it gets 🤘
Case 2 is the complete opposite:
To complete a task, engineers had to change multiple modules that are outside of their area of ownership;
Changes are large, impacting multiple files and modules;
Authors were modifying the same files to complete their tasks;
These changes are risky and most likely slow to make and review (this can be validated with Delivery Flow metrics). Codigy hotspots are based on tracking such events so teams could incrementally improve their codebase towards Case 1.
Nobody can afford full stops, but whenever a team has time to work on the technical debt, Codigy provides the most relevant & highest value targets for refactoring.
With each iteration, your team workspace will be more autonomous and easier to maintain.
Your entire codebase might be huge, but why invest effort in the part that is stable and not in use?
Codigy identifies codebase area that is active use and prioritizes hotspots that slow down your teams the most.
Each team or tribe gets insights for their area of responsibility. After resolving the hotspot this can be validated using Delivery Flow metrics:
If architectural & organization improvements make teams faster, this should be detectable with these metrics.
This page was last revised on May 27, 2022
Return to main