How coding has taught me about the importance of focus

Working with code has taught me a surprising amount about running a business, especially when it comes to building systems that actually hold up over time.

Sometimes code gets built in different ways.

There is a UNIX programming philosophy that says a script should do one thing and do it well. If you need more sophisticated functionality you connect scripts together to achieve the entire goal. This keeps code modular and easier to maintain.

Joomla, for example, follows this philosophy beautifully. Its modular structure makes it easy to add just what you need—and just as easy to leave out what you don’t. That’s a big reason we love it so much: it scales with you, without unnecessary clutter.

I recently found myself in a situation where I had a script that did something well, and I just needed one little exception to the overall rule. At first, it seemed silly to write a whole new script for this one little exception.

This happens all the time.  As developers, we often ask ourselves: At what point do I refactor the code and break everything out into its own script instead of just making adjustments to the current script to cover a new use case?

It's always a judgment call and a cost/benefit analysis: In the short term refactoring is all cost and no benefit. In the long term the code tends to be more resilient.   One thing not working as expected is often less likely to take down a bigger process. Making changes is also faster and easier when code is modular.  

What does this mean for business?

Sometimes you have a system or process that works—mostly. But then you run into a small exception. One little thing that doesn’t quite fit the way everything else runs. It feels silly to build a whole new system just for that one odd case.

This kind of thing happens all the time. The real question is: when is it worth it to break things apart and redesign how the whole system works?

That’s always a judgment call. In the short term, making that change is all effort with no immediate payoff. But over time, breaking things into smaller, more focused pieces usually makes the whole system more stable. If something breaks, it’s less likely to take everything else down with it. And when you do need to make updates, it’s way easier to tweak just one part instead of untangling the whole thing.

It’s like cooking for a crowd using one big pot.

Maybe you’ve got a stew that mostly works for everyone—but someone can’t have garlic, another is gluten-free, and one kid won’t eat anything green. At first, it seems easier to just keep adding exceptions to that one pot. But pretty soon it’s a mess. Eventually, it makes more sense to serve things in separate dishes. It takes more time up front—but it’s cleaner, easier to adjust, and everyone ends up with something that works for them.

Abraham Lincoln once said if you gave him six hours to chop down a tree, he would spend the first four sharpening his axe.  Whether it’s code or your operations, building focused, flexible systems pays off.   If your current setup feels bloated or brittle, maybe it’s time to sharpen the axe.