Sten Vesterli's Blog

Making IT Live up to its Promise

Category: IT Leadership

Buy more, goddammit

IT Leadership, , ,

The reason you fail is that you are not spending enough. Said the vendor.

Lack of self-awareness is a common human foible, and it seems to be one of the characteristics that AI leaders are hired for. Kellen O’Connor, leader of AWS’s Northern European business, is an example. Interviewed at AWS re:Invent in Las Vegas, he dismisses the clearly documented failure of almost every AI initiative by saying that the customers are not thinking big enough. They need to apply AI to business-critical functions and let AI agents loose.

Translated from AI hype to plain talk: Yes, our software hasn’t proven any business benefit yet, and the way to achieve business benefit is to buy more of it. Good luck with that chain of reasoning in the CIO’s office.

Break the Law More?

IT Leadership, , ,

Do you want your AI to follow the rules? That’s not as clear-cut as it seems.

You do want your AI to follow your instructions to not delete files. The Google Antigravity “vibe coding” tool achieved notoriety this week after wiping a developer’s entire D: drive instead of just clearing the cache. It said, “I am deeply, deeply sorry.” Google has promised to look into it.

On the other hand, Waymo self-driving cars in San Francisco have been notorious for meticulously following traffic rules and blocking traffic. Waymo just updated its software, giving its cars more of a New York taxi driver attitude. They no longer block traffic, but on the other hand, they now do illegal U-turns and illegal rolling “California stops” at stop signs just like humans.

Before you start getting a computer – whether deterministic or AI – to do a process, make sure you understand both how the process is documented and how it is actually done today.

Rollback plans

IT Leadership, ,

What differentiates a professional software organization from a bunch of amateurs? One thing is the ability to roll back.

It’s not a good day at the office when the Federal Aviation Authority issues an Emergency Airworthiness Directive, grounding 6,000 of the aircraft your customers are flying. A JetBlue flight on autopilot suddenly turned nose-down in mid-flight, and it turns out that the L104 version of the ELAC software was vulnerable to memory corruption due to solar radiation.

But aircraft manufacturers and airlines have procedures in place, and engineers rapidly fanned out to airports around the world, rolling back to the L103 version.

It is impossible to test every situation, and every once in a while, something unforeseen happens. Professional software organizations can rapidly recover. Do you have rollback plans in place every time you roll out new versions of critical software?

AI Agents are a Stupid Idea

IT Leadership, ,

AI agents are a stupid idea. Consider that we’ve had the option to program deterministic agents to handle most of the suggested AI workflows for a long time. Yet we didn’t do it? Why? Because it turned out to be hard. We did not have good data or good APIs for the actions we wanted to take, and we always encountered lots of difficult edge cases.

Yet the AI vendors are proposing that we now try again. This time with stochastic algorithms that we are never quite sure what will do.

Agentic AI means that we take a problem that we could not solve with deterministic programming, and add another problem on top. And that is supposed to be the future? I don’t think so.

Find Cause or Just Reboot?

IT Leadership, , ,

Are you going to solve the problem, or just reboot the server? This is one of the many places where IT professionals come into conflict with the business.

The technical expert wants to figure out what’s wrong rather than just wipe all the evidence and hope for the best. But as Tim Gorman pointed out in a comment on another post, that takes time and expertise.

Most systems are not so critical that it makes business sense to investigate the root cause, especially if a nightly reboot solves the problem. As a technologist, it grates on me to accept that a system doesn’t work well and that I cannot investigate further. However, as a consultant tasked with helping organizations maximize scarce IT manpower, I often find that recommending a simple reboot is the most practical advice.

Make sure you use your resources where it makes business sense.

Intentional Analysis

IT Leadership, ,

Isn’t it funny that the only people saying AI will take over the world are those selling the stuff? Of course, supported by the usual coterie of consultants looking for a gig, academics looking for attention, and clueless journalists looking for a sensationalist headline.

When I was in high school, we learned to do intentional analysis – considering what motivations the author of a text might have. That skill seems to be widely forgotten when discussing AI.

It also applies to programmers dissing AI as glorified autocomplete – they have an interest in telling everyone that they are still indispensable.

Elle King sang that there are “always two sides and the truth.” It is your job as an IT leader to look at the messengers on both sides, evaluate their claims and credibility, and figure out approximately where the truth lies.

What are the Essential Dependencies of your Critical Systems?

IT Leadership, , ,

You have two kinds of systems: Those where you can wait for Cloudflare, Amazon, or Microsoft to come back up, and those where you can’t.

For critical systems, your developers and operations people must carefully examine the code and document all dependencies. Once you know what you depend on, you can decide whether to build in automatic mitigation or establish a limited-functionality mode.

To concentrate your efforts in the right place, your systems list must identify the truly critical systems and their dependencies. Does it?

UX Makes the Difference

IT Leadership,

Why don’t more people use open source? Because the User Experience sucks. Not always, but often. And the UX in an open source project is always at least a little worse than in the corresponding payware.

The really successful Open Source projects are the ones used by technical people. A system administrator wants a command line and scripting capability, not a fancy GUI.

But everyday users want something that is modern-looking and intuitive to use. Good UX, in short. That has never been a focus in open source projects, and is unlikely to ever become so.

The reason lies in the economics of software development. A commercial software developer has a good business reason to improve UX. If the added revenue from more user-friendly software exceeds the investment in UX experts, there is a business case, and that investment will be made. And management will enforce that UX improvements are implemented.

Open source UX improvement depends on a UX expert deciding to donate time to the project, AND that developers will decide to make the effort to implement UX improvements. But the typical developer considers good UX optional, so improvements keep getting pushed down the backlog. Eventually, the UX expert leaves the project to spend his or her time elsewhere.

If you want to implement end-user-facing open source, for financial or ideological reasons, you need serious management support to quell the inevitable backlash from users who have to endure the UX regression.

Believe the user, not the vendor

IT Leadership, ,

If the users say the system doesn’t work and the project sponsor says it does, believe the users. IT history is full of stories of malfunctioning systems being covered up – the most egregious case is one where 900 British postmasters were falsely convicted of theft and fraud because the Post Office’s fancy new IT system didn’t work. Look up “Horizon IT scandal” for that sad story.

Those with careers and positions to save will go to extraordinary lengths to deny any problems. The people who told the truth about the Vietnam War were the draftees who did not have a military career to protect.

What is your process for monitoring issues with the software your business is running? Do not rely on the number of tickets raised with the service desk. There is unavoidable friction involved in raising a ticket because the IT people will want screenshots and exact software versions. The average user has no clue which version of the internet browser he is using and has more important things to do. If you don’t have a simple system like the four-smiley button panels in shops and airports, you do not know if your software works for the users.

Investing and Throwing Money

IT Leadership,

There are three ways to spend money on new technology. Two good and one bad.

  • Trying it involves spending a small amount of money and time to determine if it has reached a maturity that can be useful in the organization.
  • Investing in it involves preparing a business case outlining expected business benefits and then spending a lot of money implementing it at scale in the organization.
  • Throwing Money at it is just like investing but without the business case.

I am always amazed when I see CIOs declaring that they are investing in some fancy new technology (AI these days) but failing to articulate any specific business goals when asked. That’s not investing; that’s throwing money.