The Folly of Promises Before Practicalities

When Reality Meets Design

In a moment of lucid piquancy, we have come to realise that reality has a way of touching realism in ways so radically unexpected that a rethink is required. As I have written elsewhere, in my earlier posts on our laptop remediation activity, the theory and the terrain are rarely the same country.

I say this whilst appreciating the amount of work that has gone into crafting a "perfect" solution, only to find it unsuitable, or challenged by inconvenient situations that threaten the very premises we thought had accounted for everything.

Where Solutions Are Tested

When a solution is put to the test in a real-world setting, you find the gaps in your thinking first; then you discover the ways in which the common, the outlier, the exceptional, or the impossible render your solution inadequate.

In our case, a deployment to just 0.2% of the cohort revealed issues that will remain insurmountable until we have better data. Only then can we skew the solution towards those we can genuinely help.

What unsettles me is the arithmetic of it. If we are already encountering this many blockers with so tiny a group of testers, then the impact on the full 100%, had this gone out early, would have been more than a disaster; it would have been an overwhelming failure of insight and foresight, the very faculties none of us can afford to lack.

An AI-generated infographic on the blog content. (Click to enlarge.)

I remember a comment I made in an earlier blog: "we were working with architects whose confidence outpaced their familiarity with the environment in which their solution was meant to run." To use a colloquialism, the rubber has hit the tarmac and the tacks are flying.

The Value of Restraint

Within this morass lies the urgency to get the solution out, yet our initial reviews and feedback suggest that my reticence has forestalled a catastrophe. Restraint, however, never receives the honour it so well deserves.

We are at an impasse: how do we find normalisation amidst this chaos, so that a subset of the solution's settings can go out to the largest majority whilst we decide how to handle the difficult ones, and whether it is even worth our while to tackle them?

Promise Before Practicality

The biggest failing of this whole exercise is that promises were made long before the practicalities were addressed. The architects gave their assurances to the business before ever consulting the implementors on whether those ideas could be delivered, and that ordering, the pledge preceding feasibility, is where the trouble was seeded.

If you are not seeing through the glass clearly, you should not be gambling on the reality of the little you can see.

So, we do the only honest thing left to us: we wait for the data first, because only the data can tell us who we are truly able to help, and we promise nothing until it does.

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

Blog - A Picasso No One Can Repaint

A Gemini Notebook AI Podcast on this blog

A Picasso No One Can Repaint

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

A Gemini Notebook AI Podcast on this blog

When the Backstop Becomes the Plan

From Doldrums to Hope

The days carry varying degrees of emotional toll, from the palpable to the expectant; the feeling that you may not be pulling your weight gives way to the exhilaration of success, because what was once intractable became resolvable.

We have moved from a week that seemed to present diminishing returns to one that appears to offer appreciating results. While we are not totally out of the doldrums, there is hope on the horizon, and things have been better than expected.

Governance Left Behind

Yet we get embroiled in administrative issues that should have had governance born from contractual obligation, including the clear requirement specifications that would apply to an architectural design, with guidelines for solutions to be crafted on agreed policy.

A backstop activity, meant only to tide us over until automation could take hold, has evolved into the core solution. This is because resources will not be committed first and, evidently, the architectural element is missing altogether.

Shortcuts Over Policy

The project manager, under pressure to deliver, has short-circuited the process, favouring the concept of ease over the policy guidelines that should govern it. The ideas are lifted off a contract statement and put into play, leaving the implementation resting on broad assumptions.

What we hear is that it must be done because the contract demands it; what we do not have is any documentation describing what is actually to be done. The best element of guidance to materialise today came in an email. However, can governance be run from an email, you wonder?

That is why this is being escalated. I am not convinced a proper resolution will be forthcoming before the pressure to act overwhelms the tendency to err on the side of caution; not out of any impossibility to perform, but because of the absence of governance that informs the processes required.

A Google NotebookLM AI Podcast on this blog

Incredible India: The rime, the downtime and what may apply

There is more to this place

Sometimes I wonder about being in such a beautiful country and finding oneself preoccupied with other priorities until that one free day that is a Sunday.

The daily narrative tends to be concerned with where I am staying and where I am receiving training, but there is definitely much more to India than what I have experienced or New Delhi at that.

Stickier than plain dust

I did not get too much sleep last night before I had to get up at 7:00AM and after the morning ablutions I made for breakfast. Having been told the milk served at breakfast was whole milk, I picked up a bowl for cornflakes.

Then I saw the bag from which the cornflakes had been poured into a bigger bowl, it did not look like Kelloggs, so I reached for it out of curiosity only to feel greasy grime all over the bag as if it had been kept in some unmentionably dirty place for an indeterminate time. I probably should have bothered more about the content of the bag but after the difficulty in getting the grime off my fingers with about 5 wipes, my appetite for cornflakes had disappeared.

Once again, I had pawpaw and pineapple slices for breakfast and just got out in time to catch the bus to the training centre on seats in the back that were not made for any comfort at all.

Still down for an email frown

The wireless internet connection issue that had not been resolved since 11:30AM the day before was still a problem, the only word I had to mention to the receptionist was “apparently” it summed up the matter.

At about 10:30AM, I asked the reception for her USB mobile internet dongle and had about 30 minutes online to read my email, respond to another and submit a complaint about the wireless internet problem to Koenig Solutions Customer Care and copying in my original contacts.

I basically stressed the importance of having the connection, the fact that the service was to be expected, the need for an immediate resolution and the demand for an alternative solution at no additional cost to myself.

Within 10 minutes of my sending the email, the receptionist popped in to say the wireless internet service had been restored. Since I did not receive a response to my email, I cannot really take credit for the notion that my email might have expedited things, I have no cause to complain if the service is restored.

Keeping up with the train

The training today was fast-paced and interesting, much of the material was familiar and at the same time the misunderstood areas were so succinctly explained for my enlightenment.

I downed 3 cans of Red Bull almost to no avail but was alert enough to catch things and raise questions about unclear topics, time just flew and it was almost 5:00PM by the time we covered the proposed topics for discussion.

Another cock-up

Back at the hotel, though tired, I learnt a trainee colleague was to embark on a long journey overnight to another training centre; the personnel having failed to contact him by email when they could not get him via a telephone call to alert him to the fact that no trainer for his scheduled course was available in New Delhi – an unfortunate lack of initiative and a gross administrative cock-up.

I exerted myself and broke sweat on the cross-trainer gym equipment and the abdominal exercise machine before a shower and dinner which was rice and cutlets of lamb, the chef having excelled himself once again.

For the rest

I did not have the presence of mind to realise the internet connection at the inn was also down but after dinner, I was informed the problem had been resolved – I was introduced to all the inn staff who I warmly greeted with a firm handshake and settled for a cup of sweet milky coffee as it is made in these parts courtesy of the concierge.

The day closes with an early night, a stirring in about 2 hours for my pills and hopes for a restful night in readiness for another day.