Scalability: Your Future Self Will Thank You

You're the new guy on the team and you're finished with onboarding. You take on your first assignment: add a feature, modify an existing feature... whatever.

But as you dig into the code, you can see that numerous generations of developers have worked on this project, and each one seemed to have their own unique vision of how to get from point A to point B. In other words, DRY was abandoned a long time ago, and the only way you're going to finish your assignment is to bring in your own techniques, adding your code to an already ugly pile.

Where does scalability enter the project?

Modularity is the key to scaling, but it can be challenging as projects grow and different devs put their hands on it and everyone has a slightly different approach. Over time you find that pieces that should be reusable aren’t treated that way.

There’s the component built by someone in 2018 that does the same thing as the slightly differently named component built by someone in 2019 that does the same thing that you need to do today. In order for scalability to be achieved, it needs to be a core principle that guides the project from the beginning.

Incremental design

The scrum technique of breaking work up into digestible pieces is key because by design you are seeking ways to make your code modular. When we are in the envisioning or technical discovery phases, we avoid waterfall planning... but once the build is underway and new feature requests come in, we can get into a waterfall-coding mentality if we are not careful.

If you find this to be the case, then maybe it's time to revisit why we shunned waterfall planning to begin with.

Vertical slicing

Horizontal slicing of work leads to everyone working in their own silo. Front end is front end, middleware is middleware... it's almost as if each of us is working on a different project rather than collaborating. This is not conducive to our goal of designing for scale.

Vertical slicing of work helps so that multiple eyes are on each piece of the project. Not only does this lead to better collaboration, but it also allows a better chance that someone on the team knows of code that could be reused here.

Putting it together

Combining the agile concepts of building in digestible increments and slicing work vertically means that each piece of code that goes out will have been exposed to as many eyes on the team as possible. It's not just the PO who needs to know all of the ingredients in the sausage; it's each of us. And maintaining that design mindset will go a long way toward built-in scalability.You're the new guy on the team and you're finished with onboarding. You take on your first assignment: add a feature, modify an existing feature... whatever.

But as you dig into the code, you can see that numerous generations of developers have worked on this project, and each one seemed to have their own unique vision of how to get from point A to point B. In other words, DRY was abandoned a long time ago, and the only way you're going to finish your assignment is to bring in your own techniques, adding your code to an already ugly pile.

Where does scalability enter the project?

Modularity is the key to scaling, but it can be challenging as projects grow and different devs put their hands on it and everyone has a slightly different approach. Over time you find that pieces that should be reusable aren’t treated that way.

There’s the component built by someone in 2018 that does the same thing as the slightly differently named component built by someone in 2019 that does the same thing that you need to do today. In order for scalability to be achieved, it needs to be a core principle that guides the project from the beginning.

Incremental design

The scrum technique of breaking work up into digestible pieces is key because by design you are seeking ways to make your code modular. When we are in the envisioning or technical discovery phases, we avoid waterfall planning... but once the build is underway and new feature requests come in, we can get into a waterfall-coding mentality if we are not careful.

If you find this to be the case, then maybe it's time to revisit why we shunned waterfall planning to begin with.

Vertical slicing

Horizontal slicing of work leads to everyone working in their own silo. Front end is front end, middleware is middleware... it's almost as if each of us is working on a different project rather than collaborating. This is not conducive to our goal of designing for scale.

Vertical slicing of work helps so that multiple eyes are on each piece of the project. Not only does this lead to better collaboration, but it also allows a better chance that someone on the team knows of code that could be reused here.

Putting it together

Combining the agile concepts of building in digestible increments and slicing work vertically means that each piece of code that goes out will have been exposed to as many eyes on the team as possible. It's not just the PO who needs to know all of the ingredients in the sausage; it's each of us. And maintaining that design mindset will go a long way toward built-in scalability.