This week we have a guest columnist — KJR’s own web developer, Kimberly Lewis:

This is a follow up to last week’s column, to explain my biggest issue in web dev — one businesses that want successful web projects should be aware of:

Spend more, not less, on software.

Yep, I’m talking about everyone’s least favorite add-on cost. And I’m going to say something other open-source devs (I am one) will probably dislike.

Free isn’t always better

In fact, IS Survivor was a great test case of exactly why you want to pay extra for certain things. I paid for an inexpensive WordPress theme. (For those unacquainted with WordPress, themes are what control the look and functionality of your site, and they come at various price points.) I started with free themes. Six different ones, to be exact. The problem with free is that you get amateurish design, and worse functionality and configurability.

While I can deal with not-so-great design, I can’t put up with bad functionality and overly limited configurability. While I could consider going in and writing custom code within the theme by making what’s called a “Child Theme,” that would add weeks of concentrated work onto the job, and therefore a serious added cost.

Long term, a premium theme would be a better option. Now it’s just a matter of determining price point.

I like some of the more expensive themes. Why? Out of the box they have a great layout, lots of added functionality and customization, and plenty of extra support for when things don’t go according to plan. In my opinion, it’s worth it to prevent some extra costs.

Here is where I drag my father on his own website like the cheeky little brat of a daughter I don’t mind being. My dad is nothing if not cheap. He really, really didn’t want a premium theme. We compromised on an inexpensive but not free theme that fit the previous site’s look and feel, had the customization I wanted, but, due to the low cost, lacked a lot of the extra functionality I would have had with a higher end theme.

We’ve been paying for the decision ever since.

The limited functionality, combined with my father’s preference for displaying the entire post in full on the home page, resulted in immediate problems displaying archive and search results. My choices: either plugins, or adding a half-dozen additional pages of code into the theme. (Once again, for non-WordPress developers, a plugin is a software add-on I can install for added functionality without coding.)

This led to me trying 25 (yes, this is accurate. I kept track) different plugins for the archive list. I got refunds for 10, and all but one was incapable of handling the sheer number of columns in the archive. I’ll give Dad credit: He’s a persistent and voluminous writer.

In this case, free was the only choice — literally the only one that wasn’t breaking. Unfortunately, it’s ugly. Sorry. Not much I can do about that.

Search was the bigger problem. We started with a free trial for the best search engine on the market: Algolia Search. It’s good. It’s really good. It’s also horrifically expensive, but I’d hoped we could get away with the free version.

For the same reasons as the archive plugin, we can’t. And paying for it on a smaller site like IS Survivor is like taking out a mosquito with a thermonuclear bomb (although I’m originally from Minnesota, so I understand the temptation): too much power, too much cost for a site this small.

So now we have a dilemma. Do I go ahead and find a free search plugin, or do I use a paid plugin?

The pros of a paid plugin are, once again, customization, support, clean integration, and no ads. Yes, often you get ads on something if you don’t pay for it.

The cons of the free ones are lack of clean integration (Google Search WP, I’m looking at you), less customization, no support except from other users, many of whom have hacked the living daylights out of the plugin, and often compromised functionality.

This is a matter of cost vs. worth, and it goes all the way back to the decision to purchase an inexpensive theme.

If we’d gone with a premium theme that out of the box had everything we needed, but was also much more expensive, we’d have ended up spending exactly the same as we’re paying now. This is what businesses have to think about. Sometimes free or inexpensive will do the job. That’s great. But in case it doesn’t, be prepared to pay more than you were planning on to fix the problems “excessive frugality” can cause.

If you’re curious: I bought a single use license for a search engine plugin. Hope you like the result.

Why was there was no Keep the Joint Running last week? No, I hadn’t lost interest. www.issurvivor.com was in the throes of a major re-plumbing effort, and an unexpected glitch (is there any other kind?) delayed the cutover from dev to prod.

Like any sensible used-to-be-technical website owner, I had contracted out the work. And like any sensible parent, I contracted it out to one of my offspring — my daughter Kimberly, a budding contract developer who, like any offspring lacking sense when it comes to a parent, agreed to handle the job.

Along the way we learned (or, in many cases re-learned) a few things worth sharing:

  • Semi-technical users are more dangerous than non-technical ones.

Agile practitioners know to describe requirements in terms of “user stories.” I described my requirements functionally instead, because I knew how I wanted my website to behave.

Except that, of course, what I “knew” was constrained by what I knew, resulting in Kimberly having to engage in quite a bit of patient explanation.

Your semi-technical users undoubtedly drive similar needs for developer patience.

  • Free when you can; buy when you can’t; build when there’s no alternative. I’d expected Kimberly to start with a base WordPress template and add custom code from there. Kimberly, a talented developer, was nonetheless wiser than I. She bought the initial WordPress template and added free plug-ins to achieve what I needed.

Do your development teams embrace free?

GitHub and its brethren can jumpstart the development of all kinds of functionality. Sure there are risks. But ask yourself which is more time-consuming: Developing functionality from scratch, or analyzing someone else’s code for risks before using it.

  • Don’t mess with packaged software. When I didn’t like something about what the new site looked like or how it behaved, and it couldn’t be fixed using adjustable parameters, I often asked Kimberly to tweak the template’s php code. Kimberly reminded me that this would make the site unmaintainable … unless I’d be willing to pay her every time updates appear.

This is, of course, old news to all of us: When commercial software doesn’t do what your business needs it to do, what you don’t do to solve the problem is mess with the core code. I knew this. Knowing better didn’t stop me from suggesting it.

  • Never skip stress testing. For managing the archives, Kimberly tried 25 different plug-ins before finding one that didn’t crash from the sheer number and overall volume of my 21+ years of publishing a column a week.

Just because code works with your test data, that doesn’t mean it will work in production.

  • Don’t trust the cloud. It’s something we know but often won’t admit: Our important files all live on our personal hard drives as well as the cloud, just in case. Whether it’s Dropbox, OneNote, Google Drive, or your corporate SharePoint site, critical files can disappear, even without the magic of synchronization that can propagate deletions just as easily as they can make copies of new or changed files.

In our case, when the time came to deploy, Kimberly pressed my new web hosting service’s magic migrate twanger, only to watch her hard work disappear into bit heaven. She called tech support to ask them to restore from backup (they do back everything up) only to learn that the glitch that caused everything to disappear also caused the backup to disappear.

  • Figuring things out takes longer than developing what you’ve figured out. With no usable backup, Kimberly had to recreate her work from scratch. That took less than a day, because at that point she knew exactly what she needed to do.
  • Test after deployment, too. Just because Operations has a magic deploy twanger doesn’t mean it always works. In our case, once Kimberly got the site deployed it turned out the Search function returned the wrong results. The problem: A corrupted index. Easy to fix once detected.
  • Persistence matters most. This isn’t new more than all the rest isn’t new: Something going wrong isn’t a problem. Giving up when something goes wrong is a problem. It’s old advice: If you assume there’s a way to recover you might be wrong. But if you assume there’s no way to recover, you’ll certainly be right.

And finally … yes, in addition to being what I hope is a useful column, this is a thinly veiled ad for Kimberly’s web development services. I figure if the POTUS can promote his daughter’s line of clothing, I can certainly promote my daughter’s professional services.

Let me know if you’d like me to connect you.