Building a methodology for personal scalability

Congratulations! You’ve just made the final code commit to a project you’ve been working on for what seems like an eternity. The client is happy, tests are passing, your QC checklist is complete and now you’re sitting back watching the deployment in progress. You’re done — time to move on to the next project.

Enjoy that moment.

It may not be tomorrow, next week, or next month, but eventually your client will want to make some changes to their site. “No problem!”, you say enthusiastically. The changes they want are small, and after a brief period of getting re-acclimated with the site you’ll be able to get everything done quickly.

But now that you’re looking at the code again you are faced with the reality that this isn’t going to be as simple as you thought. Remember those !important declarations you made in the styles? A project of this size doesn’t benefit from using a CSS methodology, so what’s the harm in a few of those if it looks the way it should? How about that deeply coupled logic on the backend of the site? I mean, nothing was ever going to structurally change, so why worry about decoupling and taking a more modular approach to begin with? And of course there was barely any documentation in the form of DocBlocks or other useful commenting. What kind of developer would you be if you forgot how your code worked? Why bother with documentation when you’ll remember what every portion of code is designed to accomplish.

”Those” projects

During my career of doing agency development work, there have always been certain projects that caused dread. You know the ones. The ones that have been around for awhile, tons of developers have worked on them, and they never had any consistent methodologies applied to them. The type of project where you’d let out an audible sigh if it popped up in your schedule.

Myself and other developers would have our days overrun by what should have been fairly simple changes that ended up taking hours. I wish I could say the end result was just a loss of time, but it really becomes more of a domino effect. You’re now over time on this task and refactoring, even a bit, is out of the question. Just put something that works in there and cross it off your list. Great, now the project has even more issues. Hopefully it’s not on your schedule next time.

And what about the other tasks you needed to accomplish? Well, now you have less time for those and you’re also irritated. Sounds like the perfect breeding ground for some more rushed coding decisions to me.

And thus the cycle continues.

Thinking about scalability as part of your process

If you’re finding yourself faced with problems like this on a regular basis you’re probably running up against issues with scalability. Not scalability in the DevOps sense, or even scalability in terms of application performance, but scalability as a methodology within the foundation of your code base designed to allow it to grow over time with relative ease.

Let’s take a look at why some developers, and teams, face these issues repeatedly and why they continue to reappear:

Not enough time!

You’ve seen these issues with scalability arise before and you’ve identified them. Unfortunately, your schedule is overloaded and what you’re currently working on needed to be finished yesterday. The next project will be different because you’ll have more time.

Knowledge gaps

You know the language you’re working in has constructs available that can help build a foundation for scalability, but you’ve never used them. Is this really the time to jump into the unknown? Better play it safe and stick with what you know for now. The next project will be different because you’ll learn more about your language between now and then.

You believe it’s a losing battle

You’ve acknowledged the issues that arise in your projects, but you don’t see a connection between them. Why waste time modifying your workflow if these problems will always exist? The next project will be different because the challenges that arise are always unique and that’s just how it is – there’s no way around it.

Switching to a scalability-first mindset

So how do we fix this? How do we become better at thinking in terms of scalability? The answer is simple: make it part of your process.

After every project you complete, whether it was a pleasure to work on or a nightmare, it’s important to take time to reflect on it and identify what went right, what went wrong, what’s working, and what isn’t.

I know this reflection isn’t something to look forward to. You’re tired and don’t want to think about that project anymore. I get it, believe me I do, but this reflection is critical to your growth as a developer.

Whenever I add a new element of scalability to my development workflow, it’s typically never as the result of looking back on one project. It usually takes several projects until I can clearly identify where my weak spots are and how I can help them.

After reflecting on one project you might be eager to attempt to solve all the issues you’ve identified with a new framework or library that could have been helpful on the project. Now, those tools certainly can help you, but they can also obscure the data that only time can show you. Always be mindful that you’re tracking the root cause of problems across your projects.

How has my own scalability methodology evolved?

Developers like straight-forward solutions. If you’re stuck on how to accomplish a specific task in code, odds are there’s a solution out there somewhere. While there can exist some general mental frameworks for solving scalability issues, the bulk of the process is going to be personal.

However, since we as developers do love examples, here are some highlights from my own development journey of the problems I faced and how I modified my own workflow to alleviate them:

My CSS was messy

For a long time I had never given much thought to how I wrote CSS. Sure, I knew which properties to use and had a general understanding of specificity, but I never worried much about how I structured my code, especially when it came to inheritance within the cascade and the ability to easily override styles.

It didn’t become a major problem until I started building larger sites with more complex styling requirements. Revisiting projects after launch to either address client concerns or add in functionality became much larger tasks than they should have been. I had heard of CSS methodologies before but didn’t spend much time looking into them. I ended up taking another look at BEM and decided to try it out on the next project I started. The difference wasn’t immediate, but after a few rounds of post-launch updates I realized that nearly all the inheritance issues I had in my styles were gone. Thinking in that methodology quickly became second nature and it’s my go-to method of writing CSS to this day for any project no matter the size.

Making common code modular

Throughout my career I’ve built a significant amount of WordPress sites. All of them were built from scratch and as a result I was generating boilerplate code that was being shared between sites. Originally, the process of sharing this boilerplate code was in the form of copying and pasting between the sites. As the amount of sites I was working on grew, this became a problem in the form of remembering which site contained the code I was looking for and also how to approach updates when I found bugs, since each site would need to be updated manually. All of this started to become more and more time consuming.

My solution here was to extract all of the common logic into a Composer package that is a dependency on each site. I originally wondered if the setup process for it was going to be worth it, but it quickly proved its worth in the form of saved time. Now all of this reusable logic was contained and organized semantically in one package that could be updated on any site easily with a simple package update.

I’m still using this package currently and anytime I find myself reusing code at all, even if it’s the first time, it goes into the package. The only downside is that you do have to think about backwards compatibility and handle deprecations appropriately, but that’s turned out to be an extremely minor tradeoff to the benefits provided.

Final thoughts

For me, the focus on this methodology for scalability has been one of the most important parts of my development career. The process of reflecting on problems I encounter frequently, identifying the underlying cause, and then making a conscious effort to ease or alleviate that cause has paid off time and time again.

This should be a repeatable process with your own methodologies for scalability evolving over time. It’s not going to be a one and done situation where you think about it for a period of time and then consider it set in stone.

Of course, having a methodology for scalability doesn’t prevent problems from occurring. All projects, as similar as they can be sometimes, are ultimately unique and as a result will end up having unique problems. However, with a scalability methodology in place you’ll be far better equipped to deal with those unique challenges without also being burdened by a code base that needlessly gets in your way.

If you don’t have a process like this for yourself, I’d encourage you to start one. The process isn’t glamorous and it’s not made up of the certainties that we as developers strive for. It’s subjective, slow, and involves being critical of yourself and your shortcomings. There will be bumps in the road and not everything will work, but stick with it. Eventually you’ll find yourself moving faster and with more certainty.

And those old projects that cause dread? Over time you’ll find that far less of them, if any, come into existence. No code base is ever perfect, and there are issues that you will miss, but there should be significantly less friction when revisiting older projects. Your own development methodologies will change as a result of this process and you’ll start to see your older work as snapshots on the timeline of personal growth.