The Power of Software Architecture: Shaping Engineering Culture

Engineering culture plays a crucial role in shaping the quality and performance of software — we all know that. But what’s less obvious is the fact that it works both ways!

I claim, the right software architecture has the power to completely transform the software development culture.

When I started my role as a Web Architect at Natural Intelligence, one of the goals I set for myself was to identify the pain points in the development processes and address them.

One such point I found was the state of the front-end development ecosystem, which, in my opinion, was in an unmaintained condition. From outdated infrastructure and tools to the lack of united standards and best practices.

Due to a lack of documentation and appropriate tools, much of the code and processes were difficult to discover, and as a result, people were duplicating the code and reinventing the wheel again and again.

In addition to this, the development environment combined with the organizational structure created a situation where there was almost no sharing of knowledge and code between the developers from the different teams.

Worst of all was that some people felt that this situation could not be changed because they thought the organization will not invest major time of its developers to do an infra upgrade.

So we started to think about how can we fix the situation and finally we came up with a proposal to redesign the front-end infrastructure and rebuild it from scratch.

Probably, at this point, some of you will ask: but why build something new if you can improve and fix the existing one?

I’ll tell you why…

There are several reasons why it might be better to build a completely new software infrastructure instead of improving the existing one:

1. Technical Debt: If the existing infrastructure is outdated, poorly designed, or has been patched up multiple times, it can accumulate technical debt. Technical debt refers to the accumulated costs of short-term fixes and workarounds that are required to keep the existing system running, which can slow down development, increase maintenance costs, and introduce more bugs.
2. Scalability: It is often more difficult to retrofit existing software infrastructure to accommodate new requirements than it is to start a new one with a scalable design.
3. Innovation: Sometimes, the existing infrastructure may not be flexible enough to accommodate new features and innovations. In such cases, building a new infrastructure can enable the development of a more modern and feature-rich system.

In other words, sometimes building a completely new software infrastructure is like renovating a house. You might think that just fixing a few things here and there will do the trick, but once you start peeling back the layers, you realize there’s more rot and termites than you thought. It might be better to just demolish the whole thing and start from scratch, rather than dealing with a house that’s held together by duct tape and wishful thinking. Plus, it’s always fun to smash things with a sledgehammer, right?

Now, let’s go through the plan and understand each of its components and its impact on the end goal.

1. Greenfield development: building from scratch, without the constraints of an existing legacy code or infrastructure.

A fresh start and a chance to work on something exciting and innovative can improve developer motivation and satisfaction by providing them with a positive and engaging environment, greater creative freedom, and opportunities to learn and grow.

Developers working on a greenfield project have the opportunity to explore new technologies and development practices and have complete control over the codebase, which can lead to a greater sense of ownership and accountability for the project.

2. Design system and Storybook: A game changer in the frontend development process.

On the one hand, a Design system helps ensure consistency in the visual design of a project. By providing a shared set of guidelines, components, and patterns, teams can work together more efficiently and create a more cohesive design and user experience.

On the other hand, Storybook provides a centralized location for developers to access and share UI components, easy documentation, a visual interface for testing, and integration with other development tools. By using Storybook, teams can improve collaboration, reduce duplications, and ensure consistency in the implementation of the UI.

3. Monorepo: The enabler platform for efficient collaboration and streamlined front-end development across multiple teams.

Monorepo empowers collaboration by providing a centralized codebase for all front-end projects. It enables teams to share knowledge and expertise, making it easier to enforce consistency in coding standards and best practices.

Managing all the codebase in a single repository can significantly impact the software development process, quality, and time to market.

These are the three main concepts that complement each other and together constitute a holistic solution with which we set out.

Today, almost two years after, we have:

1. Improved quality, efficiency, and productivity: With a new and improved front-end infrastructure, developers can work more efficiently and effectively. The Monorepo allows us easier to enforce consistency in coding standards and best practices across the entire codebase. Additionally, it simplifies the process of deploying updates and changes across multiple applications. Integration of typescript and visual testing allows for testing changes across multiple applications simultaneously, which helps catch issues earlier, giving us greater confidence in our quality.
2. Enhanced user and developer experience: By using a design system and Storybook, we can easily create shared features and experiences across multiple teams and projects. Storybook provides us with a great platform for documenting and discovering components which makes it easy for developers to find and reuse existing components, rather than building new ones from scratch.
3. Better maintenance and scalability: By starting fresh with a new software infrastructure, we can avoid technical debt, and ensure scalability for future requirements. We removed all our legacy code and packages and replaced them with native implementations or more modern and lightweight alternatives. We removed ‘Zepto’ which previously was used for the client binding and replaced it with react SSR and partial hydration. With a scalable design, the system can easily adapt to changing needs and accommodate new features and innovations.
4. Positive engineering culture: We established a positive and engaging environment for developers which lead to increased motivation, job satisfaction, and retention of talent.

In summary, I can say that we have had a significant impact not just on the better overall productivity, quality, and performance of software, but as well as the satisfaction and retention of the development teams. To be more dramatic I’d say that it changed the entire behavioral perception in our front-end development ecosystem.

SWE culture is like a team sport. It takes communication, coordination, and trust to achieve a common goal — creating high-quality software. However, just like a sports team can’t succeed if everyone is doing their own thing, R&D can also suffer if there is a lack of cooperation among the dev teams.

That’s where the right software architecture comes in. It’s like a playbook that everyone can follow to ensure they’re all on the same page. By implementing a shared architecture, developers can have a common understanding of the system’s components, how they interact with each other, and how changes to one component can impact others. This promotes collaboration and helps everyone work towards the same end goal.