All Posts in App Dev Methodologies

|In: App Dev Methodologies|Last Updated:

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

|In: App Dev Methodologies|Last Updated:

‘Tis the time of year we’re supposed to give thanks. I’d follow suit, but KJR isn’t about following suit. In that spirit … among the curses of my personal existence is that when I hear just about any four-syllable word or phrase, not setting it to the tune of Oklahoma! is close to impossible. See if you can avoid it.

Halitosis! makes most toothpastes hide away in fear.

It drives your friends away, and your pastor pray

That he sees you in his rear-view mirror …

No? How about:

Folger’s coffee! Is hot, black, bitter, and has caffeine.

It doesn’t taste as good, as coffee should,

But it’s better than drinking Mr. Clean …

See? It’s like a monstrous earworm generator.

Speaking of earworms, you’ll be delighted to know researchers are working tirelessly to figure out what separates earworms from other music. Science marches on. Maybe they’ll find a cure for this horror that afflicts so many.

Don’t bet your life savings. That isn’t how the world works. You and I both know what will really happen: Marketers from around the globe will take advantage of this research to stick their messages ever more firmly in our heads.

If only they’d use their newfound powers for good.

Speaking of using newfound powers for good, last week we raised the question, what ever happened to inexpensive end-user computing (EUC) tools? This used to be a thriving software market segment, with products like dBase, Paradox, FoxPro, Access, DataEase, R:Base, and DataFlex competing on price, features, and performance for the hearts of end-users and independent developers around the world.

Now? There are products, but except for Access, which Microsoft increasingly treats as a forgotten stepchild, they’re too expensive to encourage widespread use, and they lack sufficient market presence to instill confidence in their staying power.

Except, that is, for the worst-explained product in the history of computing, SharePoint.

SharePoint folders! are just like shared folders but more slow.

Their taxonomies, reproduce like fleas, while their contents grow and grow and grow …

MAKE IT STOP!!!

Sorry. Where was I? Oh, that’s right, SharePoint, winner of the Rodney Dangerfield Can’t Get No Respect award ten years running.

Aside from the sludge-like performance of most implementations, the biggest problem with SharePoint is how few people know what it is and can do. Mostly, it’s deployed as a document management solution, without the document management. Which is to say, its taxonomies are managed just like server-based shared folders — they’re mostly ad hoc rather than designed and enforced, so what’s the point?

SharePoint has a raft of other features, which some enterprising training company might profitably list in order of declining visibility. Lord knows I’m not qualified to do this, except for being confident of what the last, least visible features would be: SharePoint provides a reasonably competent set of EUC development tools.

It lets users: Define tables (which for some unaccountable reason SharePoint calls “lists,”); join tables together (SharePoint calls this “linking lists”); create forms (SharePoint does call them “forms,” so that’s something); and define workflows.

And it has integration capabilities.

Not that yours truly understands any of this in enough depth to speak from authority. My personal experience with SharePoint is pretty much limited to using it for sharing project data and documents.

Is SharePoint the best tool for EUC app dev? From a features-and-functionality perspective, almost certainly not. But when evaluating software, features and functionality aren’t the entire ballgame. Whatever its flaws, SharePoint has three significant advantages.

The first is that you’ve probably already licensed it, so the incremental cost of making it available for EUC app dev is going to be less than licensing something else.

Advantage #2: If you already have SharePoint, you have SharePoint administrators and help desk staff who are accustomed to it. You won’t be starting from scratch.

The third advantage is much the same as when you have a repair job to do and the only tools available are a Swiss army knife and a roll of duct tape. They might not be ideal, but they’ll still give you a better result than Band-Aids and chewing gum.

Which is to say, SharePoint might not be the best tool in the drawer, but it probably does achieve the exalted state of good enough.

Comments