ManagementSpeak: One quick question …

Translation: This project will never end.

Alternate translation: This conversation will never end.

Long-time subscriber Conrad Macina explains the difference between a quick question and a quick answer.

Why was there was no Keep the Joint Running last week? No, I hadn’t lost interest. 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.