HomeApp Dev Methodologies

SharePoint: The exalted state of good enough?

Like Tweet Pin it Share Share Email

‘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 (7)

  • I always thought sharepoint was Facebook for the corporation.

    Since it is wrapped around “sharing,” I don’t see how it’d be a good fit for the end user computing which is focused on helping a single user solve his or her own problem.

  • What? No mention of the super powerful Excel add-in’s Power Query and PowerPivot? These two tools are superpowers for data crunching EUC.
    Use them to analyse all sources of data from .csv, .xml, sqlserver and Hadoop. Backwards and forwards compatible with Excel 2010 to 2016.
    Use them to build end user owned BI in hours not weeks.

  • I’ve spent at least 15 years telling people that Access is possibly the best prototyping tool available for intranet development.

    The only reason (slight exaggeration) not to use Access is that it’s still basically a single-user app. But I can create the schema and forms for a real, working application in a few hours and hand it off to the dev team to convert it to a SQL back-end with the UI in whatever language they like.

    I’m convince the reason more teams don’t do this is that (WARNING: gross generalization incoming) most Windows developers treat databases as glorified filesystems that are “someone else’s problem”.

  • I’ve always regarded SharePoint as a write only file system. I can drop files there and never find them again. When someone does find something useful by accident, we publish the URL to a list–a Wiki at my last company, OneNote at my current company–so that that specific document will be retrievable in the future. We use shared network folders for anything we want to reuse.

  • If I understand SharePoint correctly (always a dubious claim) it’s intended as an integration platform supporting DevOps. Doing cool things with it essentially requires the creation (or acquisition) of ‘web parts’ in order to provide meaningful functionality, which needs to be designed in … by design. InfoPath suffers from the same problem of needing the organization to drink the Kool-Ade (or is it Flavor-Ade?) in order to make it work as intended by integrating it into both the infrastructure and the culture.

Comments are closed.