03 Feb 2022
A common refrain from developers is “We have too much tech debt! We need to tackle it to
speed up!” It’s hard to argue with the sentiment - badly written code or outdated software does
take considerably more effort to maintain than code that follows current best practices. However,
saying we have too much tech debt is not useful, because it’s not specific enough. You can’t create
a vague “tackle tech debt” project and expect to get sponsorship from the business for the work.
If you’re lucky enough to have a portion of your time available to be used for engineering
directed projects then you’re still unlikely to be successful with a vague tech debt project.
Getting agreement for what tech debt actually is is nigh-on impossible. Everyone
has their own pet peeve that they will want to tackle as part of that project.
My solution to this problem is to avoid using the phrase tech debt. Sometimes tech debt is clear -
it might be a database that is outside of its support lifecycle or a library that is many versions
behind the current release. More common is that when people say “tech debt” they mean things like
code that is not as testable as they would like, or which follows some patterns that they declare
to be an anti-pattern. While there is broad agreement about what constitutes good code, the more
detailed you get the more it becomes about personal opinions.
13 Jan 2022
In November 2021 I gave a virtual talk as part of the IT Non-Stop 2021 Conference. Here is a recording of that talk.
03 Dec 2021
Recently my collegue Chris Sheldon posted an article titled
“Under Pressure”. It’s excellent so please take a few minutes
to have a read of it.
Ok, are you back? Great. Chris talks in part about feeling like he misses absorbing knowledge through osmosis in an office.
Osmosis, in case you’ve forgotten your biology lessons, is the spontaneous passage of something through a semipermeable
membrane. In this case, we’re talking about knowledge entering your head without you needing to consciously do anything
05 Nov 2021
Imagine you’re making a change to a codebase you don’t like. Testing is difficult and you don’t have a
good understanding of how all the parts of the system fit together. It’s tempting to just do a bit
of cursory testing, deploy it to production and keep your fingers crossed. This is not a pleasant
situation to be in, and will inevitably lead to production incidents, sad developers and cross
As a manager, if you encounter a situation like this you’ve got a choice to make about how to fix it.
Instinctively you might want to put more processes in place around deployment and testing. Maybe kick
off a project to refactor the code base and make testing easier.
Maybe you can reduce failed deployments, but at what cost? Slower development caused by extra
bureaucracy and more policies to follow is going increase friction, delay releases and
eventually lead to an unhappier team.
14 Oct 2021
Recently I went on holiday to the island of Jersey in the Channel Islands. As an electric car owner this
currently requires more planning than I would like. Inevitably, running an electric car on holiday is not
quite as convenient as being able to charge your car up at home, or being able to pop into a petrol station
and fill up in a couple of minutes. There are three 50kw chargers on the island, which can get me from
20% to 90%+ in just under an hour. Given the size of the island a full battery will last for five or six
days, so we expected this to be ok.
Although we’ve owned a Tesla for around nine months at this point our only drive longer than the range of
the car was to Northern Ireland and back, which necessitated a single stop in each direction at a Tesla
Supercharger and was quick and easy, exactly what you’d hope for. While we were there we were able to charge
using a three-pin plug where we were staying, so charge was not an issue. Unfortunately, the rented accommodation
we were staying in on Jersey didn’t have a plug near the car park, so charging overnight was not an option.