[DDD] Other metaphors for technical debt

A while ago I witnessed an interesting conversation about alternatives to the term technical debt.

I think it’s interesting to explore those alternative metaphors a little bit: they may shed some light on what technical debt actually is, how to think about it.

This is particularly important since it can be so frustrating to get non-technical people to understand it, and that it must in fact be addressed.

And it doesn’t hurt for us to explore the concept as well.

[DDD] Technical Debt

Technical Debt is a well-known concept in software development. It reflects the implied cost of additional work which is caused by cutting corners, sacrificing quality for speed.

Some also add other aspects to this definition, such as the accumulation of weaknesses in a codebase as it grows and matures: architecture decisions that don’t quite fit anymore, haphazard workarounds (and then workarounds to workarounds, etc).

I’m frequently surprised that even experienced software engineers are unfamiliar with the term. They’re familiar with the concept, of course.

DevOps is not for us

[Reading time: 2 minutes 13 seconds]

Today I had an interesting conversation with a LinkedIn contact, CEO of a company specialising in embedded systems.

He echoed a sentiment I encounter very often in embedded systems:

“Haha! Applying DevOps to embedded sounds great but 10 years away from now :-) Security, resource requirements, … "

I think he made it too easy for himself to dismiss it that easily out of hand, but I suspect he was just trying to bait me into a discussion :-D

[DDD] From Silos to Autonomous Teams

[Reading time: 1 minutes 52 seconds]

One of the goals of DevOps is to create autonomous teams. Autonomy comes from being entitled to making your own decisions, and having the necessary tools and knowledge to execute these decisions: not depending on anyone else.

The antithesis to this integrated structure is a specialist/function-based department structure: “silos”, in DevOps lingo.

To give an example of what I mean: in a siloed organisation you might have separate (say) database, sysadmin, frontend and backend departments, all working together to build a product.

We're living in the 1950s idea of 2020

As I was on a video call today, it dawned on me that we’re stuck in the past’s idea of the future.

If you look at futuristic article in a 1950s magazine, it had all the usual trappings: atomic flying cars, smooth bucket seats in living rooms – and video telephone booths.

You know, with a regular handset, and a screen, where you could call your aunt to wish her a happy birthday.

[DDD] The DevOps testing T

[Reading time: 3 minutes 54 seconds]

There’s something that has been brewing in my mind for a while: a different way of looking at software QA.

Talking about it is a bit funny, in that it’s subtle. Some of you may read this and find nothing new (and you really might not – I won’t delude myself to imagine I’m the first or only person to have thought of this).