All Posts in App Dev Methodologies

|In: App Dev Methodologies|Last Updated:

I’m giving myself a Memorial Day break. I didn’t post anything yesterday, and today is a re-run, from, as the Beatles might have sung, 20 years ago today.

It’s a bit esoteric, but even more relevant today than when I first wrote it.

Take a look and let me know what you think about it.

– Bob

# # #

If there’s one certainty in our business, it’s that useful, lightweight frameworks turn into bloated, productivity-destroying methodologies.

And so it was with considerable trepidation last week that I suggested we need another methodology, to do for Content Management Systems (CMSs — the technologies we use to manage unstructured information) what normalization and related techniques do for relational database management systems (“Unstructured data design — the missing methodology,” KJR, 5/17/2010).

But we do. As evidence, I offer many of the comments and e-mails I received suggesting we don’t: Most pointed to the existence of well-developed tools that allow us to attach metadata to “unstructured content objects” (documents, spreadsheets, presentations, digital photos, videos and such, which we might as well acronymize now and have done with it: For our purposes they’re now officially “UCOs”).

And many more pointing out that search obviates the need for categorization.

Let’s handle search first, because it’s easier: Search is Google listing 16,345,321,568 UCOs that might have what you’re looking for. It’s also what leads to (for example) searches for “globe,” “sphere,” “orb,” and “ball” yielding entirely different results.

Search is what you do when you don’t have useful categories.

And then there’s metadata — the subject that proves we don’t have what we need. Because while we have the ability to attach metadata to UCOs, we have only ad hoc methods for deciding what that metadata should be.

Some readers suggested this might be a solved problem. Books are UCOs, and librarians have been categorizing them for centuries. Between the Dewey Decimal System and the Library of Congress Classification, surely there’s a sound basis on which to build.

Maybe there is. I’m skeptical but not knowledgeable enough to state with confidence they won’t work. I’m skeptical because their primary purpose is to place books in known locations in the library so they can be readily found, which means they’re probably similar to the single folder trees we need to move beyond.

What we need, that is, is the ability to place one UCO in as many different locations as anyone might logically expect to find it. To use one of my own books as an example, Leading IT: The Toughest Job in the World would fit in at least these categories: Leadership, Information Technology, Staffing, Decision-making, Motivation, Culture change, and Communication skills.

The official name for the discipline of defining knowledge domains … what we’re trying to do … is ontology. It’s an active area of development, including the creation of standards (such as OWL, which puzzlingly stands for “Web Ontology Language” instead of “Ontology Web Language,” but let it pass).

From what I’ve been able to determine, though, it appears everything being developed thus far falls under the heading of tools, with a useful methodology nowhere in sight. This is, perhaps, unsurprising as it appears philosophers have been discussing the subject at least since Aristotle first introduced it 2,350 years ago or so, without yet arriving at a consensus.

It could be awhile.

Of course, philosophers are obliged to develop systems so universal they apply, not only to our universe, but to all possible universes. Such is the nature of universal truth.

We don’t need to be quite so ambitious. We merely need to categorize information about our businesses. To get the ball rolling, I’ll offer up the framework we’ve synthesized at IT Catalysts. It enumerates ten topics that together completely describe any business — five internal and five external. They are:

Internal

  • People: The individual human beings who staff a business.
  • Processes: How people do their work.
  • Technologies: The tools people use to perform the roles they play in business processes.
  • Structure: Organizational structures, facilities, governance, accounting, and compensation — how the business is put together and interconnected.
  • Culture: The learned behavior people exhibit in response to their environment, and the shared attitudes that underlie it.

External

  • Products: Whatever the business sells to generate profitable revenue.
  • Customers: Whoever makes or influences buying decisions about the products a business sells.
  • Pricing: What the business charges for its products, terms and conditions of purchase, and the underlying principles that lead to them.
  • Marketplace: The business “ecosystem” in which the company exists, including customer groupings, competitors, partners, and suppliers.
  • Messages: How and what the business communicates with its marketplace.

There you go — a free gift, if you’ll forgive the redundancy. Just break these topics down into sub-topics and sub-sub-topics. The result should be a workable classification scheme.

Let me know when you’re done.

Comments

|In: App Dev Methodologies|Last Updated:

Warning: If you’re planning to watch any Marvel Universe movies but somehow just haven’t gotten around to it, plot spoilers follow. But then, on the other hand, if you haven’t already watched any of these movies you probably never will, which will make what follows just a bit less compelling. Such are the hazards of building an intellectual edifice on a pop culture foundation.

I have a weakness for superhero movies. I also have a weakness for chewing on Hey, Waitasec! questions that don’t occur to me until a few days later.

That’s questions like why, in the first Avengers movie, during the whole battle for New York City, the entire U.S. Airforce never bothered to show up.

But never mind that. We can chalk it up to dramatic license, because had a squadron or two of advanced jet fighters equipped with heat seeking missiles joined in, this would have just cramped our superheroes’ style(s).

Black Panther doesn’t get off so easily.

Oh, don’t be like that. My gripe: The entire plot centers on the most technologically advanced country on the planet, Wakanda, relying on a governance model built on an inherited monarchy complemented with trial by combat.

What could possibly go wrong?

Plenty could, and in the movie it does. What fixes it? If you’re thinking it’s everyone in Wakanda saying, “Hey, waitasec! Shouldn’t we be convening a constitutional convention?” you’d be wrong. It ends up getting fixed by a second trial by combat, with everyone in Wakanda perfectly willing to follow the lead of a bullying psychopath should he win round two as well.

He doesn’t — the good guy wins this one, luckily enough — but really, this is a terrible way for a nation to decide on who is going to lead it.

What does this have to do with you and your leadership responsibilities?

Well, maybe it’s a stretch, but some executives do seem to admire the trial-by-combat approach to choosing who gets to decide what, and how. They encourage inter-manager rivalries on the grounds that this leads to more energy and initiative.

Which it does. That the energy and initiative are largely wasted doesn’t seem to matter very much.

Less of a stretch is something fundamental in any organization, from the board of directors on down: Figuring out how to choose the right person to put in charge of each area of responsibility.

The lesson from Black Panther? Strip away the plot and specific characters and you come to this: The tests through which Wakanda chooses its leader have nothing at all to do with the tests its leader has to deal with when holding its leadership office.

Well, in the movie it sorta does because in it the leader doesn’t lead all that much. He acts like those fighting alongside him only better. Yes, he’s inspirational, but no, he doesn’t seem to think in terms of strategy, tactics, and logistics all that much.

Or, more broadly, that leaders of any organization need to think in terms of … well, in terms of the eight tasks of leadership.

Anyway, when choosing the leaders who report to you, don’t make this mistake. Too many times, executives outsmart themselves when choosing managers, when an unstructured conversation built around “These are the challenges you’re going to face if I put you in the job. How would you go about facing them?” would do the job far better, and far more naturally.

But enough carping about Black Panther. Let’s carp about The Avengers: The Age of Ultron instead, and more specifically, how much better things would have turned out had Tony Stark understood a core principle of application development: You always test software. Testing it before you put it in production is better.

I mean seriously: Launching a full-fledged, self-motivated AI into PROD … in this case, a real-world environment in which it had full access to a wide range of destructive weaponry … without first examining its behavior in TEST? Seriously?

Now to be fair, had Tony Stark followed standard testing protocols followed by ITIL-style change management, the movie would have been horrifically dull.

But since there was a movie, and in it you can see what happens with insufficient testing protocols, maybe this would be a good time to review your own testing methods … not only when you deploy software, but also when you deploy new processes and practices that affect how Real Paying Customers do business with your business.

I’m on vacation this week, so I’ll leave you to finish it. Your homework assignment: In the Comments, post your Hey, Waitasec! analysis of Captain America: Civil War.

And yes, plot spoilers are encouraged.

Comments