When Fast Isn’t Fast — the Bad of Incremental Updates

Practicing a “get it done” attitude, I've recently added a constant stream of features to my site. Most visitors wouldn‘t notice. They aren‘t dropping by to relish my web design, nor are they interested in my latest tweaks to enhance their experience. Nope, they‘re here to read an article. Or, more likely, they‘re lost—but I digress. If the content is there, the looks, assuming the basics are present, is secondary.

Yet, having a pleasing look with familiar features is a plus. Every time I run across a bug, I‘m quick to squash it. The problem, though, is every bug ends up being a deep run into the code. What should be a simple CSS fix becomes a hack and slash of the view news routine. Making responsive images becomes an exercise in following spaghetti code. Enough already!

Recognizing that you‘ve bottomed out.

Iterative or agile design isn‘t a cure all. While allowing for more speed, you have to avoid a few traps as well. Speed isn‘t an excuse for good design. Sometimes, you need to take a step back to avoid the predicament I face: unmanageable code.

It isn‘t that I‘m not trying. To the contrary, I broke things into modules, separated out functions, leveraged reuse, etc. But the river is only so wide. At some point, my boat of code started to bottom out. It is obvious now, but I either need to dredge the river or build a new boat.

If we think of the CMS I‘m using as the boat—sticking with the analogy, you‘ll discover that it has built up over time. My CMS originates from four different code bases, each with their own versions. As changes piled up, it resulted in code bloat and code rot. As new features were added, expanding what you could do with the system, they were often bolted on without much change to how the system worked.

Code rot is all that code that is there for compatibility reasons. It isn‘t maintained, hanging around for the one or two people that wanted to upgrade all those years ago. It should have been removed, but it was easier to leave it in than try to fix mods or themes that used it.

What you end up with is a bigger boat. What was sleek and light, is now cluttered and heavy. Dredging the river isn‘t the answer because you‘ll never stop. For me, my code just keeps getting bigger. I may be fast, but I kept snagging on the bottom.

A real world snag.

As an example, let‘s dig into the read time feature I added not too long ago. To help a reader gauge the length of an article, I calculate a time to read and display it. It is a simple addition, requiring just one line of code:

# Create read time
$readtime = int(((split /\s+/, $message)/200)+1);

Yet, that one line assumes that $message is the same everywhere. Sadly, it isn‘t, requiring me to hunt down the differences and fix them. Of course, making them the same introduced bugs that I need to fix.

One place you might want that read time displayed is on the front page with the article summaries. Since I trim the $message before applying other fixes, it wouldn‘t display correct. That required me to process a copy of the message before I created the summary.

That same code also creates a cache file that didn't include the read time. Okay, time to add some code to capture that data and later pull it out of the cache file. The end result looks great, but I kept having to replicate that line of code to all the places it was used.

Why is this so? Because the code wasn‘t designed to scale. I was getting things done faster, but porting those changes to other sites is proving to be difficult.

Time to build a boat.

I wanted to be fast, but I didn‘t put the effort into updating that old code. Instead of writing a new feature, perhaps I should have written a new application. It is obvious that the code needs an overhaul. To go faster, I need to step back and go slow for a bit. Not stop, though—that is another trap that is all too easy to fall into.

In fact, I‘m doing that now with another site. I‘m overhauling my old 3v as many of the old API's are broken. Instead of just fix things, I‘m moving everything to a new site with scalability baked in. Now, I can add and remove signatures without having to overhaul the site. Sure, it's a bit more work, but the end result is that I can build on it. And, to be honest, it hasn‘t been that hard.

Which is the point. It is easy to hide behind the sexy parts of a process, and ignore the rest. There are trade-offs and, by no means, do you have to always rebuild the boat. It‘s a matter of recognizing that you need to rework things to get even faster.

When you see there is a problem, act on it. You‘ll be glad you did.