Back to resources

Introducing Modularity and Creating Componentization

Dev Processes
Tech Debt

26 August, 2021

Anna Nicanorova
Anna Nicanorova

CTO at Annalect

Anna Nicanorova, VP of Engineering at Annalect, broadly speaks about the degree to which a system’s components can be separated and recombined with the benefit of flexibility and variety in use.

Problem

What is the holy grail of software development? In my opinion, it is modularity and componentization. Although modularization as a framework has been widely discussed and debated for the past 30 years, unfortunately, we, as practising software developers in big enterprises, still do not have the discipline to implement it. The biggest problem with code is that it rots. As the software community trailblazer with inventions and improvements, what is “new & innovative” today becomes “old & outdated” tomorrow. So, what ends up happening are nuclear rewrites: we abandon our existing codebases to adopt a better, newer system and spend a long time replicating existing functionalities under new frameworks. But this is extremely expensive both from a time and effort perspective.

Modularity allows for a more gradual and natural process to update code. Instead of massive rewrites and redesigns, we can rewrite only one module at a time and do it fast. We can do it without interfering with the current core functionality of systems. Modularity asl allows “safe experiments” - instead of blindly adopting a new library/framework, modularization allows us to first take it on a test ride with just a couple of modules and to explore advantages and promised benefits.

It sounds like a great vision, but executing this in real life is plain difficult. Many have failed. It requires a lot of time, high investment, long-term commitment and diligent discipline.

Actions taken

While conceptually "modularized approach to writing code" makes sense, from my experience, team capacity and existing roadmap commitments do not allow any bandwidth to even contemplate it as a building standard. For the past 2 years, my team has been gradually pursuing modularization, gradually breaking monoliths. While we have made some good headway, in my opinion, we still have a long way to go. Here is how we have approached it.

  • We separated all our front-end code and created a component library with standard shared components.
  • We separated all of the APIs and converged them into a cross-app API layer
  • We have started converting the remaining backends into microservices

Separating “battle for modularization” into 3 separate initiatives allowed us to fight 3 different battles instead of one big “war for modularization”. Change is incremental. When organizing initiatives people try to tackle everything at once. Pacing ourselves on various projects had allowed us to gradually make improvements incorporating and adjusting to learnings over time.

Every initiative above also got its own name. Branding was important since it made the initiative more tangible and had allowed us to negotiate with our product team for small percentages of time to be allocated to these initiatives, instead of blocking large time frames and calling it “tech debt”.

Finally, having an evangelist for every initiative and having the team buy-in was critical for the success of every initiative. Top-down projects where people do not have emotional buy-in tend to die down. Making “modularization” a year goal did not get us anywhere. However, having a lead on every initiative and requesting people to contribute ensures that component libraries and API layers get built.

Lessons learned

  • Break up big critical initiatives like “tech-debts” & “componentization” into specific projects to make slower but incremental and gradual progress over time.
  • Change is inevitable. Modularity is just the benevolent way to embrace it.
  • Nothing is permanent. Rebuilds will happen. Set up a mentality that whatever you have in hand may need to be thrown away. With that in mind, architect accordingly.
  • For every initiative get a leader and evangelists and ask for teams to pitch in. People will support an initiative only when they are contributing to it.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Balancing Technical Debt Innovation: How Roadmaps for Development Help Your Company Succeed

4 May

Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.

Alignment
Leadership
Impact
Roadmap
Tech Debt
Career Path
Brad Jayakody

Brad Jayakody

Director of Engineering at Motorway

Why You Should Take Technology Risks in Product Development

25 April

Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.

Innovation / Experiment
Product
Scaling Team
Dev Processes
Matias Pizarro

Matias Pizarro

CTO and VP of Residents at ComunidadFeliz

Company Growth: The Good, the Bad and the Ugly

18 March

Renaldi, Director of Engineering at Boku Inc., shares his guide for improving problem-plague processes into strategic initiatives.

Dev Processes
Feedback
Strategy
Team Processes
Renaldi Renaldi

Renaldi Renaldi

Director of Engineering at Boku Inc

The Evolution of a Startup Co-Founder

15 March

Shawn Sullivan, Co-founder & CTO at Phase Genomics, shares how his career has spanned from working at a tech giant to co-founding a startup in every stage of his growth.

Changing A Company
Dev Processes
Company Culture
Impact
Convincing
Changing Company
Career Path
Shawn Sullivan

Shawn Sullivan

Cofounder & CTO at Phase Genomics

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.