Business Tech: Flawgorithms
Johnny is a boy. Johnny has freckles . Therefore, all boys have freckles. This is a syllogism: two true statements which are followed by a false conclusion which seems to be supported by the facts. I've met a lot of business professionals who make decisions based on logic which is even less solid. Are you running a business — or supporting one — based on flawgorithms?
Product vs. Project
One of my pet peeves is when I buy a product and find out that I've received a project. Recently, I worked on a Drupal site. Granted, I didn't buy Drupal (in that I was not charged for the software) but I bought it in the sense of my spending time, trouble, and effort on it. Annette, my new friend, picks a template. She and I, both technical, dig in, looking for how to change the pictures on the slider. Guess what? We find instructions on how to edit the HTML of the module. There is no interface for selecting the pictures. Everything is hard coded.
This theme is a project . Software that requires you to poke at the source to make it work isn't complete. A product should have interfaces for the obvious needs. I accept that something esoteric — I need to handle currency fluctuations by adding a variable conversion charge, for example — might require custom programming, but that should be the exception. Not knowing the difference between a finished product and a work-in-progress is a logical failure; a flawgorithm.
I'm sure all of us have seen this in far more critical settings. Annette simply picked another theme and we were back to work. When the project is your primary business software, that's another thing entirely. I watched a client move off of MultiValue and onto a project that was perhaps fifteen percent of what they needed. This was over a decade ago and I still recall walking into their office to the daily — sometimes more than daily — complaint: "The developer is pushing an update. I can't do any work until it finishes." Every change required a software change. Nothing was parametric.
Go With What You Know
If you know me, you know that I never like to find myself with only one tool for a given job. I use pretty much every flavor of MultiValue. I use several brands of SQL. I'm a big proponent of using no database on certain classes of projects. Despite that, I built a product with absolutely the wrong technology recently. My flawgorithm? Go with what you know.
I love Delphi. I've built web tools with it, GUI apps, and even some basic Android stuff. When Dan Schmitt and I developed BeBackBy, I reached for Delphi. On the Android side, it works well. For the iOS side? Not so much. Long story short: I'm learning Cordova.
Business as Usual
I recently attended a talk by David Jordan. If you don't know him, look him up. Very smart guy. I know him from our time together on the U2UG board. He tells the story of the tea kettle manufacturers who, using big data, see that they sell more black kettles than white. The flawgorithm? We need to cost-reduce white tea kettles to increase sales.
Why is that a flawgorithm? Because they are only analyzing their own data. Big data is frequently about looking at your own. That means that any color of kettle not already in production was omitted as a sales option. It means that only their own pricing history was factored into the analysis. It leaves style and other factors out of the equation.
What was David's recommendation to these theoretic kettle makers? Step back. A tea kettle is a means to an end: They make hot water. The hot water business includes K-Cup machines, which cost more than tea kettles and have better margins. The takeaway? data can be accurate and still lead to inaccurate conclusions. Looking wider for the data - looking at your business from a wider perspective - offers more solid logic.
In Disney's Sleeping Beauty, Maleficent sends her goblins to look for Aurora. Sixteen years later,one of her goblins announces that they've looked in every cradle. That's right, they'd been using the original search parameters — she's a baby — for sixteen years.
Before we snicker at that, ask yourself how much of your business software has been unaltered for a decade or more? Are you running a business with embedded logic that hasn't been reviewed in a very long time? How many of us are running reports that tip over baby carriages? We all need to examine our systems for flawgorithms.