HomeApp Dev Methodologies

Lessons from an upgrade

Like Tweet Pin it Share Share Email

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.

Comments (12)

  • Congrats on your launch!
    Helpful hint: Adding a child theme helps when you want to add additional code and you don’t want it to break on every update.

  • NOT Kimberly’s fault!

    >Why was there was no

    was and was

    Oh, no need to post…

  • Perfectly ok to describe and hawk your daughter’s web development skills.

    Of course, like all other things and previous columns you’ve written, we apparently can’t have non-political things anymore…

    And I am SICK TO DEATH of the politicization of EVERYTHING.

    Strike two, I unsubscribe next time.

    • Huh. And here I figured it was a harmless wisecrack. I’m guessing you’ll end up unsubscribing at some point, because there are leadership issues that the behavior of prominent political figures illustrate, and I see no reason to avoid using these illustrations.

      I’ve actually been quite cautious in this regard. For example as you know, I’ve been a strong proponent for a very long time of leaders relying on evidence and logic and not just trusting their guts. Not a week goes by that I don’t read multiple examples of one or more prominent figures violating this principle. I think I’ve published one mild comment on the subject.

  • Bob,

    I love your IS Survivor blog and have followed it for more years than I can count. This story of platform migration is such a great summary of lessons learned that I need to share it with our club’s webmaster and our Board of Directors. Sounds like much of your wisdom rubbed off on Kimberly. I think we could benefit from your example and her expertise. Would you be so kind to pass along her contact information so we can explore a business opportunity with her?

  • Perhaps Kimberly could write a column describing what she learned from the perspective of a young, new employee working with an older, more experienced (at least in his mind) client.

  • Site looks great. Better mobile compatibility than the last version at least for an iPhone. Did notice tapping comments reloads the whole article. Since this looks like the first comment I don’t know if 0 is causing it or a normal reaction.

    • We tried to set things up so clicking on Comments in the email jumped to the start of the Comments section, but all of the techniques we tried would have either been error-prone or unmaintainable. Sorry for the inconvenience.

  • Congrats on the upgrade. They are never easy, and the kids know more than we give them credit for.

  • Great post as usual. I agree with the idea of Kimberly posting her view of what has been going on.

  • I second the motion of getting Kimberly’s experience of things. Just don’t fire her if she doesn’t give you a sufficiently positive review!

  • Nice story. One other (indirect) lesson that could perhaps be drawn from this: It is helpful in general for the non-technical and no-longer-technical to realize what they don’t know and have appreciation for those who are capable of work of which they are incapable.

    I largely got out of development because of all-too-common business attitudes toward developers:

    – assumed to be lazy and dragging their feet because of complexity that was not understood and was not desired to be understood

    – treated more like very expensive typists than the incredible creative problem solvers that they were

    – putting the developers’ (often small) portion of the product development lifecycle under extreme scrutiny and micromanagement while the less technical front end and back end (where it existed) had zero scrutiny, schedule pressure and measurement

    – extreme double standards for predictability. Extreme accuracy expected for estimates from developers, whereas for example revenue estimates – when they were even made – were never looked at again once funding was approved.

    In my experience, this attitude is even more prevalent among MBAs than in the already-pretty-prevalent general non-technical population.

    Industrial age a-go-go.

    The work is difficult, challenging and unpredictable folks. Try it yourself if you don’t think so. Assume positive intent, and show some appreciation.

Comments are closed.