Skip to content

Legacy and tech debt are a fact of life in all software. So how can we identify the major causes and try to limit them in our development process?

This time I discuss the major causes of tech debt and put forward a way to deal with them at various levels in your organisation. Writing software is an intensely human activity and we’ll deal with the factors that making writing perfect software next-to-impossible. For at least us humans.

NOTES

Team Topologies

DDD, Refactoring and Legacy Code

Join my workshop on January 17th 2023:

https://richardwbown.com/embracing-legacy-and-tech-debt

Transcript
Richard Bown:

Hello.

Richard Bown:

Welcome to the Software Delivery Club.

Richard Bown:

My name is Richard Bown, this is episode 23.

Richard Bown:

This time, I'm continuing my descent into the philosophical trenches of

Richard Bown:

software development and delivery.

Richard Bown:

By looking at the question, how does legacy and tech debt appear.

Richard Bown:

Or the cost of change working with legacy code.

Richard Bown:

Or making tech debt and legacy work for you.

Richard Bown:

As you might know already, I'm obsessed with getting to the

Richard Bown:

bottom of tech debt and legacy.

Richard Bown:

I see them as the same thing, really take that as something that we incur as

Richard Bown:

we make choices about building software.

Richard Bown:

Legacy is something we refer to systems with, which will be on saving

Richard Bown:

perhaps all beyond our control.

Richard Bown:

Perhaps they are too full of take that for us to consider working on them anymore.

Richard Bown:

Or it's a shortcut for saying that it's something we don't want anymore.

Richard Bown:

Either way, these are systems, which we believe we want to move away from.

Richard Bown:

Despite the fact they may still be used and may still be

Richard Bown:

making us money as a company.

Richard Bown:

So I'm reading.

Richard Bown:

Michael feather's excellent book.

Richard Bown:

Working effectively with legacy code.

Richard Bown:

And it gives a lot of great tools for understanding and refactoring the code.

Richard Bown:

That you have to deal with in the average or not.

Richard Bown:

So average coding job.

Richard Bown:

The book does a great job of explaining what changes mean to our code base, how

Richard Bown:

we can offset the effect of changes or balanced them with comprehensive test

Richard Bown:

suites, plus sensible and effective and pragmatic refactoring and ways of working.

Richard Bown:

What the book doesn't explore is where the tech debt and legacy

Richard Bown:

come from in the first place.

Richard Bown:

It touches on how we get into a situation where we need to deal with it.

Richard Bown:

And how to recognize it and what to do about it, but not its Genesis.

Richard Bown:

And this is what I would like to dig into in this episode.

Richard Bown:

Additionally, I want to understand how much of this legacy and tech

Richard Bown:

debt is essential to the work of the software that you have created.

Richard Bown:

I've broken down the contributing factors into three groups, systemic,

Richard Bown:

functional, and individual.

Richard Bown:

These are the areas that forces into making a legacy and tech

Richard Bown:

debt decisions as we code.

Richard Bown:

So, what do I mean by systemic functional and individual?

Richard Bown:

Here are a few examples for each group.

Richard Bown:

Systemic factors that create, tech debt are those completely

Richard Bown:

outside of the engineer's control.

Richard Bown:

But our, within the organization's control.

Richard Bown:

For example, a deadline with lots of pressure on it.

Richard Bown:

Coding standards or house style, a way of doing things in the house.

Richard Bown:

Costs are we limited by resources, people, tools, capabilities.

Richard Bown:

Poor specifications.

Richard Bown:

A lack of support from management or just as an organization

Richard Bown:

that we don't know any better.

Richard Bown:

Our understanding or experience is too small.

Richard Bown:

Functional factors that create, tech debts are, more within the scope of

Richard Bown:

architectural decisions, such as.

Richard Bown:

The availability of specific language features or languages.

Richard Bown:

The tooling that we're using, perhaps compilers or editors or test

Richard Bown:

tools only work in a certain way and limits our ability to express

Richard Bown:

ourselves fully or as we would like.

Richard Bown:

A lack of specific tooling, effective CI tests, coverage tools, et cetera.

Richard Bown:

Constraints in the specification.

Richard Bown:

This could even extend to non-functional requirements.

Richard Bown:

That require us to structure the code in a certain way for efficiency.

Richard Bown:

Or perhaps just unhelpful or wrong architecture.

Richard Bown:

So those are some functional factors.

Richard Bown:

And finally, in the individual factors are what we do when we're actually coding

Richard Bown:

as individuals or even in teams or pairs.

Richard Bown:

Things that can drive debt here our inexperience.

Richard Bown:

Um, the wrong experience, perhaps, do you think, you know what to do?

Richard Bown:

A, lack of knowledge of the technology.

Richard Bown:

Thinking, you know what to do with the tools and the techniques.

Richard Bown:

Personal style and preference.

Richard Bown:

Of course.

Richard Bown:

Your own personal way of doing things and coding standards.

Richard Bown:

an inability to understand the specification which goes along with

Richard Bown:

perhaps a lack of seniority or experience.

Richard Bown:

The inability to question the specifications or the requirements.

Richard Bown:

Approach to coding may be different for you than it is for the rest of

Richard Bown:

the team that you're working with.

Richard Bown:

Your mentality, maybe slightly different.

Richard Bown:

Or your way of working when it comes to certain techniques like XP or.

Richard Bown:

Agile or something would be happening in your personal life at that particular day.

Richard Bown:

It could be many of these reasons or any of these reasons.

Richard Bown:

The list, especially for personal factors goes on.

Richard Bown:

The mood we're in one day to another changes and our

Richard Bown:

approach can change with that.

Richard Bown:

It is a complex domain of factors, which contribute to legacy and take debt.

Richard Bown:

When we start to list them, we see there are lots of them, but we also

Richard Bown:

see that they are intimately connected.

Richard Bown:

For example, time pressure can cause or exacerbate many of the individual factors.

Richard Bown:

You can see that legacy is a consequence of.

Richard Bown:

Speed or pressure or inexperience or changing language or tools or

Richard Bown:

features, but also many other factors.

Richard Bown:

It is therefore pretty much inevitable that something is going to cause a

Richard Bown:

legacy decisions to be made immediately.

Richard Bown:

Have you ever looked back at a piece of code you wrote years ago and thought,

Richard Bown:

whoa, I was pretty good back then.

Richard Bown:

Or have you looked back and thought, wow, what was I thinking of?

Richard Bown:

Or you think.

Richard Bown:

Wow.

Richard Bown:

Those were the days where I could do something like that.

Richard Bown:

All of these expressions.

Richard Bown:

Are of where you were and where the technology was at that particular time.

Richard Bown:

Time is an important element at play.

Richard Bown:

What may have been impossible for any given reason last year,

Richard Bown:

last month, last week, whatever.

Richard Bown:

May now be possible through a newly released language feature

Richard Bown:

or a new tool or approach or the availability of new system.

Richard Bown:

We have to make decisions many hundreds and thousands of them

Richard Bown:

every day, potentially these decisions work for the moment.

Richard Bown:

We are writing the code.

Richard Bown:

There is never a right time to write the code.

Richard Bown:

Only the right now.

Richard Bown:

That's inevitably means that every stage at every keystroke

Richard Bown:

we're committing something that won't be perfect in the future.

Richard Bown:

We're making a decision.

Richard Bown:

So, how do we know this?

Richard Bown:

Well, look how carefully most compiler writers are.

Richard Bown:

With ensuring there is backwards compatibility in there.

Richard Bown:

Compilers.

Richard Bown:

They want the code that you're writing now to be good in the future to.

Richard Bown:

They don't want to add to your burden.

Richard Bown:

Apart from if you're the writer of the swift compiler of course, a

Richard Bown:

few years ago, which was changing with breaking changes all the time.

Richard Bown:

Usually once code makes it into production.

Richard Bown:

We don't want to see it fall out to support and compiler writers,

Richard Bown:

interpreter writers, and people who create tools, which underpin us, as

Richard Bown:

software engineers, have our backs.

Richard Bown:

So by tackling.

Richard Bown:

The list of reasons for having tech debt in the first place, we can

Richard Bown:

perhaps approach a situation where we are minimizing the effects of

Richard Bown:

these factors in our organization.

Richard Bown:

So let's have a look at the list again.

Richard Bown:

And see if we can provide some guardrails.

Richard Bown:

Um, in order to make our code more future-proof.

Richard Bown:

So looking again at the systemic factors.

Richard Bown:

If there was a deadline with lots of pressure on it, then.

Richard Bown:

Make a statement about it, say that we prioritize quality and supportability.

Richard Bown:

If there's conflicts or differences within house style when it

Richard Bown:

comes to coding standards.

Richard Bown:

Then do you have any architectural decision records or ADRs?

Richard Bown:

Have you specified this already and now they're just out of date.

Richard Bown:

Do you as an organization need to make some decisions about this.

Richard Bown:

And discuss them and communicate them with everybody who's involved in creating code.

Richard Bown:

If you're limited by costs when it comes to resources.

Richard Bown:

Uh, people tools, capabilities.

Richard Bown:

Then make a decision as a business.

Richard Bown:

Do you want to be a software business?

Richard Bown:

Do you want to invest in these things to make your software better ? If

Richard Bown:

you have poor specifications.

Richard Bown:

Will you invest in your process?

Richard Bown:

Do you allow them to come through to development?

Richard Bown:

If they're not up to standard?

Richard Bown:

If there was a lack of support from management.

Richard Bown:

Do you need to educate your management and educate yourselves?

Richard Bown:

To understand what it means to be a software business.

Richard Bown:

If you don't know any better as an organization.

Richard Bown:

Do you make an effort to understand how you can serve your

Richard Bown:

customers better in the future.

Richard Bown:

For functional factors if the availability of specific language

Richard Bown:

features is a problem, then again, looking at ADR, is there a way to

Richard Bown:

investigate options for your code?

Richard Bown:

If there are constraints in the specification.

Richard Bown:

Make sure the important decisions around trade-offs between functionality

Richard Bown:

and performance are fully understood by everybody involved and discussed.

Richard Bown:

If a compromise is required, then flag it as such and make a

Richard Bown:

plan to improve the situation.

Richard Bown:

Compromises a fine, as long as they are time boxed.

Richard Bown:

And there was a commitment to revisit them at some point.

Richard Bown:

And if the architecture itself was unhelpful or unsuitable, And if

Richard Bown:

you're continuously forced into making a decision, which will

Richard Bown:

work against the architecture.

Richard Bown:

Then perhaps there are too many compromises and it's better to

Richard Bown:

step back and revisit the entire architecture at some point in the future.

Richard Bown:

Again, have a short-term plan and a longer term plan.

Richard Bown:

And understand that this will be a potentially company-wide decision,

Richard Bown:

which may take years to implement.

Richard Bown:

For individual factors.

Richard Bown:

Around experience or the wrong experience or lack of knowledge of technology.

Richard Bown:

Then get experienced.

Richard Bown:

Use mentors train up-skill.

Richard Bown:

Invest in learning about new technologies through reading,

Richard Bown:

podcasts, videos, conferences.

Richard Bown:

When it comes to personal style and preference provide

Richard Bown:

individual freedom for expression.

Richard Bown:

But agree and enforce guardrails.

Richard Bown:

Testing standards and automate as much as possible and integrate

Richard Bown:

regularly at least once a day.

Richard Bown:

If you'll stand for too junior and have the inability to understand specifications

Richard Bown:

or push back on specifications, then provide an environment for them to ask

Richard Bown:

questions and provide them support.

Richard Bown:

If the approach to coding is not what you require, then again, provide education.

Richard Bown:

If you look at these factors, you want it to some patterns about how we

Richard Bown:

can address the causes of tech debt.

Richard Bown:

At an organizational level.

Richard Bown:

There are choices to be made.

Richard Bown:

Can we acknowledge that every shortcut we take builds up tech debt.

Richard Bown:

Failure to support the business of software delivery.

Richard Bown:

We'll bury tech debt for the future.

Richard Bown:

Borrowing from Peter to pay Paul.

Richard Bown:

The debt will be incurred immediately and will be paid back

Richard Bown:

at a greater cost in the future.

Richard Bown:

This is a fundamental choice.

Richard Bown:

Decided what kind of business you are and back that type of business.

Richard Bown:

If you are a software business, then act like one.

Richard Bown:

In order to do that.

Richard Bown:

Prioritize quality architecture and people.

Richard Bown:

Your reward will be a reduced cost of change and hopefully happier

Richard Bown:

customers with a great product.

Richard Bown:

The functional factors invest in the right tools and make it architecturally

Richard Bown:

clear where the product is going.

Richard Bown:

If there are compromises to be made, then make them, but have a plan to

Richard Bown:

fix them in the longer term with a potential investment in the architecture.

Richard Bown:

At the individual level.

Richard Bown:

Provide a framework of knowledge and skills to support your engineers.

Richard Bown:

Providing backing by clear architectural decision and business direction

Richard Bown:

to create psychological safety.

Richard Bown:

Ensuring there is clear architectural direction plus support from management

Richard Bown:

in terms of tooling, training and understanding can create an environment

Richard Bown:

where it is possible to create good code the lighter on technical debt.

Richard Bown:

These approaches don't come for free, but as a trade off, it's a business decision.

Richard Bown:

Again, look at the proof around us that this works.

Richard Bown:

Look at what gene Kim says in the unicorn project around psychological safety.

Richard Bown:

One of the five ideals of software development.

Richard Bown:

Look at Team Topologies.

Richard Bown:

A team friendly humanistic approach to software development.

Richard Bown:

It gives guardrails for supporting, but allowing freedom of expression.

Richard Bown:

The humanist approach to software development is truly

Richard Bown:

about limiting tech debt.

Richard Bown:

By getting us to enjoy the process of software creation every day.

Richard Bown:

Hopefully I've given you something to think about.

Richard Bown:

As always thank you for joining me.

Richard Bown:

And please leave me a review on apple podcasts.

Richard Bown:

Or wherever you're listening to this podcast.

Richard Bown:

It's always great to get feedback.

Richard Bown:

And as Corey Quinn says, if you enjoy this podcast, then please leave a five star

Richard Bown:

review wherever you consume your podcasts.

Richard Bown:

And if you didn't enjoy this podcast, then please leave a five-star review

Richard Bown:

wherever you consume your podcasts.

Richard Bown:

This is a one man production.

Richard Bown:

And I live for your feedback.

Richard Bown:

So please get in touch with me via LinkedIn or via my website.

Richard Bown:

You can also find me via CTO problems.com.

Richard Bown:r my workshop in mid January,:Richard Bown:

I'm running a session on the practicalities of dealing with legacy

Richard Bown:

and tech debt from a coding perspective.

Richard Bown:

It's hands-on it's free.

Richard Bown:

And you can sign up by the link.

Richard Bown:

I will leave in the show notes.