Skip to main content
  1. Posts/

Maintenance and Diets

·6 mins
Tim Wicks
Short Thoughts Tech Life
Tim Wicks
Author
Tim Wicks
Cloud Engineer
Table of Contents
Maintenance and Experiments - This article is part of a series.
Part 1: This Article

Series Introduction
#

Two things have occurred to me while trying to keep my work, hobbies and life afloat. First, starting a plan and making initial progress is pretty easy and what’s much harder and much more overlooked is maintaining that momentum into the future. The second thing is that we hardly experiment or think creatively when we ought to be trying different things out due the lack of capacity or fear of being wrong. These two assertions may appear to be diametrically opposed, so in this series I would like to explain my thoughts on these ideas.

These posts arise from some thoughts on relationships between different concepts that have been rattling around my head and writing just so happens to help me make sense of them. The core elements of these concepts relate to the graphs that depict these relationships and some of the supporting ideas have come later as I have attempted to apply these abstractions at different levels and scenarios.

This first post is on maintenance and some of the concepts relating to this as it relates to myself and technology teams - an area I am familiar with due to my work.

Maintenance
#

Maintenance:

  1. the process of preserving a condition or situation or the state of being preserved.
  2. financial support provided for a person’s living expenses.

I try several diets per year and I think am on number three so far. It is easy for me to eat poorly or not put enough effort into my diet then spend a few hours planning and finding inspiration for my next way to achieve some form of weight loss. I hold myself to my new plan for a few days and everything seems to be going exactly how I want things then some unanticpated obstacle will redirect my attention to other things; work and life tires me out then the original plan is either out of mind or hardly seems like the highest priority anymore. In some sense the goal of achieving a new routine and plan is executed successfully, but the ultimate goal that the plan was created for is lost. In the context of a diet it seems very obvious that the ultimate goal of the diet is to achieve the final outcome - weight loss - but in other situations the ultimate goal is rarely in sight, thought out or achieved. To this end I think technology (IT) and software projects fall into this trap without exception.

If we are honest, most cognitive and marketing effort these days in tech is put into creative process at the start of a new idea, feature, project, product, design, etc where sales, leadership and architecture team members will agree on how to produce something new for the organisation that seemingly enables it to capture a new market or gain some capability. It is the showy side of technology that gives the impression of progress, when in most cases the engine room is flooded due to a large laceration by an iceberg and headcount needs to be reduced. Very rarely are our efforts focused on the issues that caused the engine room to flood or the ship hitting the iceberg in the first place, these are operational issues unworthy of higher levels of prioritisation.

A representation of a typical handover between a contractor and member of the operations team.[1]

But this is the crux of the issue, just like maintaining some form of adherence to a diet is better than plan and burn, so to in IT and software it is probably more important to improve current processes than focus on the next big project that builds your empire. Every technology team I have worked with has a mountain of technical debt and a handful of planned internal projects to migrate to new environments in the hope of elevating some of the stress caused by the interest accruing on this debt. This quandry is worth your attention, not only does it cause the wheels of progress to slow delivery of current projects; the indebted system causes more outages than necessary, complexity and ultimately people find better things to do and move on. Ironically, fixing these issues is rarely a priority where new capabilities and things on the company roadmap are prioritised by management. I can’t say that the fault is with management here, however, as technical teams who can see glaring issues in current system or architectural runway are rarely the best sales people for bringing this to management’s attention with a dollar figure attached to it.

The graph above is one of the inspirations for this blog post. The graph depicts a relationship between Maintenance Capability (MC) and New Things (NT) or prioritising them. Essentially where your technology’s teams effort will be allocated. The units of measurement are arbitary but I believe there exists an optimal relation such that given a certain MC you are able to work on X many NT. Working on too many NT given your MC you will have operational risk - such as outages or accumulating technical debt. Below a optimal amount of NT you will be too risk averse where competitors may be outpacing you, or you simply can do more with your technology team. As MC improves your ability to support new things scales in a quadratic relationship (parabola), this is why tech giants can support hundreds of new products across a very large geographic footprint. MC in this sense is a product of maturity of processes, tooling and staff expertise.

Once realistic expectations are set regarding the current set of features and capabilities your company’s technology offers and you somewhat meet that as an organisation your best use of effort is to ensure the longevity, stability and flexibility of that current set of technology that will allow you to deal with headwinds that may be facing your business. This is achieved through focusing on developing your position, where effort is put in to make incremental improvements to your current technology setup to achieve the aforementioned characteristics. The best maintenance occurs with tasks and processes where output is quantified in some way so incremental improvements can be assessed and measured. Over time this effort will result in technical dividends where new projects are easier to execute on and further improvements are more evident.

Generative AI is increasingly skewing this relationship between new things and making existing systems better. For it possible to create and deploy an entirely new application in an afternoon workshop, but much harder to keep this new application and existing suite of systems going against the backdrop of complexity which includes large data migrations or network changes.

Conclusion
#

In my opinion the best diet is no diet, where you reach an equilbrium between your daily energy expenditure and provide good nutrition that keeps you at a healthy weight and achieveing your exercise goals. Good habits manifest themselves so no abrupt change is required to realign you with target objectives. I think many athletes and active people that are kicking goals could safely put themselves in this group. How many tech teams could say the same thing where their good maintenance processes are simply a background process that hums along without the need for any reboot or reconfiguration? If that is you and your team I admire and applaud your efforts. As for myself I find it a fascinating area to research and dig into, where I seek to improve technical bandwidth that improve existing systems and reduce the friction of producing more.

References
#

[1] - Mr Bean - Chemistry Experiment

Maintenance and Experiments - This article is part of a series.
Part 1: This Article

Related

Self-hosting a Github Runner
·9 mins
Tim Wicks
Homelab Tech
Setting up a VM on Proxmox and configuring a Github Actions runner for use in a homelab environment.