Categories
Engineering Hives and Silos

Modernisation?

The story goes…

Business X has been using a software package for the last 20+ years to perform a critical, maybe even the most critical, function of the business.

20+ years ago this package used to be an off the shelf, install on an office PC, double-click to launch in Windows type of application. It probably looked rubbish but had a menu with 3+ levels to navigate dozens of screens with 20+ fields each to manipulate. There were only a few people that could learn and knew how to use it for some very specific tasks.

10+ years ago the vendor of that package found it easier – meaning no install, no update, no office PC – to put the same software on a bunch of servers and let users access it remotely (RDP).

Today many of these applications are still running businesses, mostly because they are cheap or because over time they became a monopoly.

Innovation at these vendors, and the businesses using them, would have stopped, if it wasn’t for a new movement.
Reluctantly, the vendors slowly added a new type of access – API – to their packages.
These dumb API-s would often look like an XML version of the screens they represent.

Business X realised they have a new option.
Rather than paying for an expensive 20+ years old application running remotely they can pay a lower fee for accessing the API.

Projects are in abundance making the transition – under the banner of Digital Transformation – from remote desktop Windows applications to web based, API led solutions.

There are so many ways these transformation projects go up in smoke.
One is where business X insists on rebuilding the same screen flow from the old desktop application.

Is this Digital Transformation? No.
Maybe modernisation? Hardly.
It is simply cost avoidance.

Categories
Engineering Hives and Silos

Tech Stack Bingo

Tech Stack Bingo is when a business has a portfolio of, seemingly random, tech they acquired (sold to) over the years.
As the projects roll in, the needs mark a match with an existing tech.
The closer the match the better. They win if no tech lingers on without a project and nothing comes in needing a new tech – BINGO.

Some sorry businesses try to cheat their way by forcing some close enough tech on the project.

This is where disaster strikes. It happens more often than one would expect, for example:

  • somebody bought the tech and now need to use it, cannot lose face (or the job)
  • everything is done with the one and only tech the organisation has some skills in (nail and hammer)

Categories
Engineering Product Management

On Measuring

Measuring code quality, productivity, technical debt is difficult.

Measuring number of lines of code; speed of delivering code; completed stories, features, epics is easy.

Do not trade quality away for comfort.

Categories
Engineering Hives and Silos

Kicking the can down the road

Technical debt sneaks up on organisations and their systems. It is inevitable.
The ability of dealing with, managing, remediating it differentiates successful businesses from the rest.

Technical debt builds up over time. It could take years for it to amount to significance. If unattended, it reaches a time when the fixing costs are higher than the return from it.
The system still produces value at this point, it has not gone bankrupt. There are even workarounds to some of the issues.
However, innovation, new feature and product introduction is not sustainable anymore – nobody wants to touch a house of cards system, or pay the premium for the overhead of dealing with the mess.

The system enters the zone of – kicking the can down the road.

Occasionally, a large(ish) investment into the existing system might be justified if it generates enough value – as opposed to replacing it entirely, which would be too expensive.

In most cases, just enough fixes are applied to keep the lights on and to keep sweating the asset for the rest of its operational life.

Minimise the effect of bad debt and extend the productive lifespan of a system by

  • Looking out for the technical debt indicators
  • Putting strategies in place for managing technical debt