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

You Do Not Get A Painter to Fix Another's Art

The Value of Vindication

Vindication comes in different ways, not to gloat or to point fingers, even if, after all is said, the concern you raised has been proven true. Good communication, alongside the ability to articulate one's thoughts even in the heat of the moment, remains the most critical skill every time.

In a long-running saga of urgency and wits, from which workplace stress can be the damaging consequence for motivation and wellbeing, withstanding authority and office in the quest to improve a proposed solution, so that it works as intended and engenders confidence, is not a battle for the fainthearted.

There are so many ways to express oneself, and the power of persuasion comes in the form of words that walk people down a reasonable lane of acknowledgement, misgiving, challenge, and requirement, before acquiescing to the notion of a willingness to engage and always help.

A Question of Ownership

In this instance, after a solution did not work as intended, a project manager had the bright idea that it was now the job of the implementor to fix the problem with a complex set of orchestration scripts; scripts that the implementor had long before determined would not deploy cleanly, for various reasons previously given but seemingly ignored.

The truth was that collaboration had never quite been on offer. What passed for it at the outset was minimal, closer to an imposition than an invitation, and it was only our steady, well-argued pushbacks that drew out any real interaction. Even then, we were working with architects whose confidence outpaced their familiarity with the environment in which their solution was meant to run.

The first line of my response was that his reading of the situation was wrong, and I then went on to make the case for why, starting with a simple analogy. Because scripts and programming are an individual's way of thinking and a style of expression for what they want to achieve, and without the full immersion of others in the coding process, "You do not get a painter to fix another artist's work of art."

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

I appreciate that there was something I could do, but what was requested was input; it could not be interpreted as taking ownership of the solution. The fundamentals of the intended solution were sound, but its enterprise deployment, so that it consistently works once rolled out, requires the inside knowledge of the implementor to point out why certain constructs will fail, so that the developer takes those ideas seriously when modifying elements of the proposed solution.

Back to the Canvas

The response of the project manager was at first patronising and then emotional, but the artist, the developer, understood the import of my message and got back to work fixing their solution, which is now in its fourth iteration and possibly still a work in progress nine days on.

As far as I was concerned, what I intended was achieved: to draw out the work of the implementor, before the solution was complete, and to inform of the essential changes and improvements needed to make it deployable.

Invariably, I believe the result would not only be fit for purpose; once fully done, all sides of development, through implementation, to the end-users would see the intended benefits the solution would offer.

The whole trajectory now sits in the slipstream of practical engagement with the implementation process, rather than in acquiring accolades from promising the client outcomes that, from the onset, would never have worked, back when the first ideas were put to us over two months ago.

Authority and Consent

One higher management person did interject in the email chain, suggesting we were involved in verbose communication; the same person who used the lexicon of grief to explain the effects of change some months ago. None of these replies required a response once the artist was back to fixing their work of art, rather than hoping another might attempt a dash of graffiti to improve it.

The authority to propose still requires the consent to implement. Badly designed systems tend to be a symptom of the same thing: responsibility placed in the wrong hands, and too little respectful engagement with those who must carry a complex solution through deployment.

Had the environment been understood from the start, much of this could have been avoided. In the workplace, this is the challenge faced by many who need the kind of articulation that ensures a solution has the best set of inputs to work.

We are not seeking perfection, just something good enough to understand, implement, manage, and hand over cleanly, when the time comes.

Related blogs

Blog - Badly Designed Systems Are Just That

Blog - Authority Without Consent

Blog - When Change Borrows the Lexicon of Grief

A Gemini Notebook AI Podcast on this blog

Thoroughness Is Not Stalling

Caution Gets the Cold Shoulder

I sometimes find myself receiving the cold shoulder because something I have been asked to do requires a bit more investigation and understanding before considering implementation.

One such situation came up towards the end of last week. A deployment from a utility set was being knocked out by a security policy. We did not realise this was an issue until an urgent investigation for actionable data could not be completed, as the tracker had already been removed by that same policy.

In layman's terms, take, for instance, a sophisticated radio jamming implementation that stops all mobile phones from communicating, except for selected phones with particular identities.

One essential phone is then brought into the environment, but not exempt from the jamming signal; it might appear to operate, but it goes blank when a call is about to be made. This is not entirely accurate in technical terms, but it paints the picture of what the situation was.

A Policy in the Way

We had blocked everything except for select elements, and another system was sending out an element that was not on that list. The element was installed, but within a set timeframe, it was removed because it was not on the list.

Obviously, this put my colleague in a quandary. They had to explain why information they assumed would always be retrievable was suddenly unavailable, and this stymied the investigation another team was trying to commence.

In the broader scheme of things, there was always a security policy, but for investigatory purposes, the tool needed an exemption to allow it to install and remain installed. The end-to-end facilitation chain had not been engaged, and hence, the failure of intent at that stage.

Rushing Ahead Without the Facts

The obvious next step was to remediate the issue by allowing the tool to install, but neither of us had full knowledge of the facts of what other parameters it needed to perform as required.

While my colleague wanted to rush out a fix, I was not convinced we had the right one. We had some knowledge of what should be done, but no guarantee it would work. In cases such as this, I would find a subset of users and/or devices to test the premise on, ascertain that everything works as intended, and then implement it under change management processes.

However, to my colleague, I was impeding the process and stalling rather than being proactive, despite my concerns and feeling that we did not have sufficient information to proceed.

Their next act was to extricate themselves from the communication chain, leaving me to face the pressure of urgent implementation without the full set of data required to have the confidence that we were doing the right thing.

Right the First Time

Earlier today, I gained some clarity on the fundamentals of the implementation, including what the sources were and where the conflicts occurred. With this, I was sufficiently informed to test the premise of my findings and, beyond that, gain the full information needed to fix the problem once and for all.

I recognise that I could be pedantic, and at times, some have suggested I am a perfectionist, which I would immediately deny. I am thorough, sometimes quite particular and meticulous; it is simply the nature of the responsibility this job carries.

An accidental deployment can so easily close down a business, and whilst this particular activity does not carry such a critical risk, there is one thought to always keep in mind.

I'd rather do it right the first time, even if it takes longer, than rush it now and have to fix the issues that arise because I did not devote the necessary time to understanding what was involved. For that reason, I make no apology. The world is not ending; it is impatience clouding better judgement.

A Google NotebookLM AI Podcast on this blog

Thinking of the wisdom of crowds

Lifted from the doorman’s view

It may now be the stuff of legend, but I cannot find the story I read some time ago about how lifts or elevators came to be built on the outside of buildings. Apparently, a prominent hotel planned to close for a long time to install elevators that required punching holes through existing floors, the construction debris rendering the hotel uninhabitable for the duration of the project.

The architects had their plans up and things were ready to go, which would have put the hotel staff out of work for months. One of the doormen heard of these plans and somewhat quipped about why they had to close the hotel and whether it was not possible to consider building the lift on the outside, thereby keeping most of the hotel business open for the duration of the said project.

From hearing to using

Someone who could influence things heard this suggestion and got the architects and designers to work on this idea which as the doorman suggested was a better way to keep the hotel going while the new lift was being installed. After the completion of the project, the outdoor lift became a draw for the clientele and the public alike.

The wisdom of crowds in a broader sense is not so much about the multitude of ideas that come in when a situation or problem is posed, but the ability to sift through the many viewpoints to see what is viable.

Some organisations get advantages out of this more than others in knowing how to pose the problem, managing the scope of those who can bring new perspectives and having the means to assess the viability through discovery, determination, development, design, deployment, and delightful.

The struggle toward delight

Delightful suggests that the outcome is beneficial, enjoyable, profitable, working, and could be improved upon with the knowledge and experience gained, and inspire to do other things.

Then again, the wisdom of crowds when not looked at pejoratively would mean one is open to new ideas by finding sources of new perspectives especially from those not steeped in the profession or expertise, in what might be both a new pair of eyes and ears brought into the conversation.

You have to wonder if you are afraid to see things differently and that your premises are challenged to the extent that you are persuaded to adopt a different stance or modify a concept to accommodate variance you had not heretofore considered. I think it is a healthy thing and where you find the opportunity to be involved in such a situation, engage it, embrace it, and learn from it.

Postscript: There are books and further academic and research work on The Wisdom of the Crowd, fallacies, crowdfunding, groupthink and so on, this blog is just a general viewpoint on some activity I was recently involved in.