Defaults Aren’t Always Good

I am responsible for a b2b system with a few dozen per-client settings, many of which are old and have defaults.  For instance, there is the grace period, which allows a limited self-service time window for clients to enter data that was missed during the normal course of business.  It seemed like a good idea at the time, but now we have a set of invisible values hidden in code holding those defaults.  And we can’t change them.

The main problem is, changing a default is an operational change to an unknown scope of clients.  On top of that, there could be clients that have the current default explicitly configured: would we want to change them, too?  It probably loops in the CEO and takes at least a week of meetings to answer that.

From a b2b business standpoint, it is actually better to require a configuration value (and let the support team view/modify it), even if it introduces the possibility of failure.  Our clients will use the normal support channel (well-oiled and always staffed) to raise the error message to us, if tech doesn’t proactively alert themselves about it.

For an ecommerce or public website where users would just leave, it’s probably more costly to “crash on error” than it is to let an errant process continue.  But if management prefers to halt and catch fire, the defaults are the opposite of that.

Finding Meaning

Two things came across my radar recently; cks talking about Job Vs Career, which is an old post, and apenwarr talking about Billionaire Math, which is not.  They’re very different, but they both give me the same “meaning of life” vibes, so let’s talk about that.

“Where am I going?” and “What do I do now that I have all this money?” are sort of the same question, just from different angles.  It’s a spiritual question, because the process of answering it has the shape of a spiritual journey.

What do you really, truly want?

It’s really hard to untangle from what everyone thinks we should want!  It’s a question that comes down to values and worth, and it takes time to uncover those values.  It takes thought, grit, commitment.  It takes looking inward to our own expectations, and deciding whether we need to hold onto those.

There’s No HealthScore™

I don’t know who needs to hear this today, but there’s no single number that defines “healthy.”

Weight and BMI don’t work.  Total cholesterol, LDL, nor triglycerides cover it.  Blood glucose or A1c, as useful as they are for diabetes, do not have specific “Health” levels.  Exercise isn’t magic, either; there’s no step count or bike computer statistic that indicates perfection.

These are all data points in a larger picture, and should be regarded as a holistic output.  There is a complex, interlinked system regulating it all, and trying to directly change one of the outputs is not likely to be helpful or sustainable.  At least, not if I don’t have a disease that is specifically related to those markers.

It took all my willpower, but I finally quit dieting.

I don’t have anything else.  There’s no general advice I can give on diet, exercise, or health care that I can be confident I will be able to stand behind for even five years.  The science isn’t there to give anyone (me included) individualized advice.  Regardless, the limited hypothesis of “there is no silver bullet to health” should withstand the test of time.  I can hope.

Simplicity can be Imaginary

There’s a comic about simplicity: how an Apple product has one place to touch, a Google product has one search field, and “your company’s app” has dozens of fields with interrelated requirements, obscure codes, strange highlighting, and “…” buttons.

The thing is, for internal or even b2b apps, the user probably knows what kind of thing they have, that they would like to search on.  If they are trying to look up a customer ID, then matching to a PO number is irrelevant; it will just take time and produce extraneous results.  If they can tell the computer directly, “Find customer #33448” then jump straight to the customer record, it saves them an extra round-trip through a search result page they didn’t need.

“Your company’s app” from the comic comes across as more of a data-entry page than the main point of interaction.  One might still organize the form along required/optional dimensions, and put auto-loaded fields in proximity with what will automatically update them.  However, to make the business happen, there’s a minimum amount of data that is genuinely required, that shouldn’t be crammed down to one textarea and parsed back out.

The Enterprise’s Goals

When I was a n00b on the internets, I heard whisperings about awful, over-complex “rule based systems” out there, somewhere.  Programmers scoffed at them for essentially being programs that were being written by non-programmers; nebulous “managers” allegedly dreamed of replacing expensive programmers with cheap office staff.  I did not understand at the time where these systems came from, if everyone seemed to think they were so bad.

Part of that answer is simple.  “Programmers aren’t ‘everyone.’” Oops.

The other part of that answer turns out to be review and auditing. Anything that exists in code is opaque to the business staff; they largely have to trust the programmers on it, or demonstrate defective outcomes. (And at that point, they need to wait for the necessary programming and deployment for it to be fixed.  If it is a big enough problem that customers or clients are exploiting in the meantime, that delay can become costly.)

Functionality that is exposed as ‘configuration data’ to the office staff becomes reviewable by other office staff, such as managers, and errors can be corrected more quickly.  External auditors can use the same review capability for their own work.  The next problem is that this data might not be flexible enough, which pushes toward the development of conditions and actions, and the rule-based system is born.

It was never about the programmers; it was about the business being able to view its own source code.