The Mad Hatter's Drawing Board
Every good farce
needs its Mad Hatter, and mine arrives armed with a drawing board. That drawing
board, the one we have returned to many times over the last six weeks, was the
receptacle of imperceptible scrawls by a mad scientist whose antics do not, on
the surface, look like a frenzy of demented absentmindedness coupled with a
sense of all-knowing confidence.
No, what comes out at
the end is what makes this a Mad Hatter you could, in your complete docility,
be persuaded to strangle. The task itself was simple enough to state: to
improve laptop performance in a tightly controlled environment.
There we were at the
end of last week, on the cusp of completing this intensive work of art, in the
sense that the automation now had snapshots, verbose logging, and
user-initiated rollbacks, all at my insistence, achieved in stages of
improvement that registered close to fifty versions of the code.
An AI-generated infographic on the blog content. (Click to enlarge.)
Two Questions
Then two questions,
from different perspectives, quite literally upset the applecart. The first was
why something that could be done by policy was being implemented by scripts. It
was possible because the architect, the same mad scientist, had tinkered with
the engine enforcing policy, in what I saw as a neat piece of coding.
The second question
concerned supportability, to which I responded that, although there was a
spectrum of knowledge available, the code presented a level of complexity that
no one would grasp beyond tweaking it. My own suspicion, if I am honest, was
that the code would eventually be ripped out rather than developed and
maintained.
I suggested it was a
work of art, the progeny of the architect, and that you will not get another
painter to daub on a Picasso. A good analogy, but probably too suggestive in
its reading, because the architect was soon back to trying to fix it. What resulted
was a new design for what the code did, and we were back to square one with
deployment by policy and preference; twenty-three tweaks had become ninety-two.
Policy Versus Scripts
The
policy-versus-scripts argument comes down to something quite practical. Policy
carries comprehensible text and well-known, configurable settings that are
recognised right across the industry when it comes to endpoint devices.
Scripts, by contrast,
are bespoke by nature, and far too many of them end up impossible to maintain
or are simply left to function with their faults until something new can
replace them. I am firmly on the side of adapting the concepts as designed and
moving them into an implementation that others can actually support.
Skimming through the
document, I could already see problems, some easy to correct, but others
requiring a total rethink. The concept remained the same in terms of what was
to be delivered, but there was a paradigm shift in the implementation that
could no longer be done in the phases the scripts were best suited to.
A Promise
Disappointed
Worse still, the
settings from the scripts did not transcribe directly into policy text; I
needed a reference website to derive the policy text for each required setting.
Then came the realisation that many of those settings from the script had no
commensurate policy text at all.
It did not help; it
merely exacerbated the amount of unnecessary work that could have been done
right the first time. I sense a kind of aversion to explaining or describing
anything that has been done, with emails and Microsoft Teams chats substituting
for this essential piece of communication that I have requested many times
before.
At the end, an XML
file that could have saved me hours of work was in the wrong format for
ingestion. None of it was helpful; a promise at first sight was, in truth, a
total disappointment deserving of excoriation, but I am too polite for that. I
have a pattern-recognition insight into things that suggests an Originally
Conditioned Distraction (OCD) to fix. At a glance, I saw that an XML delimiter
had not been properly set.
Meticulous to a Fault
Perhaps I am
meticulous to a fault, but it is to forestall and arrest faults before they
cause issues. Erring on the side of caution always trumps bludgeoning through
like a bull let loose in a china shop. Many may not agree, but you do not build
a forty-year IT career on being reckless, especially after learning from
interesting or costly mistakes earlier on.
This remains a work
in progress. I am hoping the transition from scripts to policy will hold,
though there are the various unhelpful gaps I have referred to the architect. So,
I await the response, before chivalry from the Middle Ages requests the violent
disembowelment of someone mercifully dispatched before they wreak additional
havoc on the peace of our noble workplace.
Related blogs
Blog - Authority
Without Consent
Blog - Badly
Designed Systems Are Just That
Blog - You
Do Not Get A Painter to Fix Another's Art
