When Fast Isnít Fast Ė the Bad of Incremental Updates


Recognize when to pause or slow down to go faster.

Boat, Unsplash.comPracticing 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.



Comments on this article:

No comments so far.

Write a comment:

Type The Letters You See.
[captcha image][captcha image][captcha image][captcha image][captcha image][captcha image]
not case sensitive