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

https://richardwbown.com/team-topologies/

https://richardwbown.com/ddd-refactoring-and-legacy-code/

Join my workshop on January 17th 2023:

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

Hello.

Welcome to the Software Delivery Club.

My name is Richard Bown, this is episode 23.

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

software development and delivery.

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

Or the cost of change working with legacy code.

Or making tech debt and legacy work for you.

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

bottom of tech debt and legacy.

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

we make choices about building software.

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

perhaps all beyond our control.

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

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

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

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

making us money as a company.

So I'm reading.

Michael feather's excellent book.

Working effectively with legacy code.

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

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

So average coding job.

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

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

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

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

come from in the first place.

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

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

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

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

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

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

functional, and individual.

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

debt decisions as we code.

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

Here are a few examples for each group.

Systemic factors that create, tech debt are those completely

outside of the engineer's control.

But our, within the organization's control.

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

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

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

Poor specifications.

A lack of support from management or just as an organization

that we don't know any better.

Our understanding or experience is too small.

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

architectural decisions, such as.

The availability of specific language features or languages.

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

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

ourselves fully or as we would like.

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

Constraints in the specification.

This could even extend to non-functional requirements.

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

Or perhaps just unhelpful or wrong architecture.

So those are some functional factors.

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

as individuals or even in teams or pairs.

Things that can drive debt here our inexperience.

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

A, lack of knowledge of the technology.

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

Personal style and preference.

Of course.

Your own personal way of doing things and coding standards.

an inability to understand the specification which goes along with

perhaps a lack of seniority or experience.

The inability to question the specifications or the requirements.

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

the team that you're working with.

Your mentality, maybe slightly different.

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

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

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

The list, especially for personal factors goes on.

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

approach can change with that.

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

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

see that they are intimately connected.

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

You can see that legacy is a consequence of.

Speed or pressure or inexperience or changing language or tools or

features, but also many other factors.

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

legacy decisions to be made immediately.

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

whoa, I was pretty good back then.

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

Or you think.

Wow.

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

All of these expressions.

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

Time is an important element at play.

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

last month, last week, whatever.

May now be possible through a newly released language feature

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

We have to make decisions many hundreds and thousands of them

every day, potentially these decisions work for the moment.

We are writing the code.

There is never a right time to write the code.

Only the right now.

That's inevitably means that every stage at every keystroke

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

We're making a decision.

So, how do we know this?

Well, look how carefully most compiler writers are.

With ensuring there is backwards compatibility in there.

Compilers.

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

They don't want to add to your burden.

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

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

Usually once code makes it into production.

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

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

software engineers, have our backs.

So by tackling.

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

perhaps approach a situation where we are minimizing the effects of

these factors in our organization.

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

And see if we can provide some guardrails.

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

So looking again at the systemic factors.

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

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

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

comes to coding standards.

Then do you have any architectural decision records or ADRs?

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

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

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

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

Uh, people tools, capabilities.

Then make a decision as a business.

Do you want to be a software business?

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

you have poor specifications.

Will you invest in your process?

Do you allow them to come through to development?

If they're not up to standard?

If there was a lack of support from management.

Do you need to educate your management and educate yourselves?

To understand what it means to be a software business.

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

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

customers better in the future.

For functional factors if the availability of specific language

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

investigate options for your code?

If there are constraints in the specification.

Make sure the important decisions around trade-offs between functionality

and performance are fully understood by everybody involved and discussed.

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

plan to improve the situation.

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

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

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

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

work against the architecture.

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

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

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

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

which may take years to implement.

For individual factors.

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

Then get experienced.

Use mentors train up-skill.

Invest in learning about new technologies through reading,

podcasts, videos, conferences.

When it comes to personal style and preference provide

individual freedom for expression.

But agree and enforce guardrails.

Testing standards and automate as much as possible and integrate

regularly at least once a day.

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

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

questions and provide them support.

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

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

can address the causes of tech debt.

At an organizational level.

There are choices to be made.

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

Failure to support the business of software delivery.

We'll bury tech debt for the future.

Borrowing from Peter to pay Paul.

The debt will be incurred immediately and will be paid back

at a greater cost in the future.

This is a fundamental choice.

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

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

In order to do that.

Prioritize quality architecture and people.

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

customers with a great product.

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

clear where the product is going.

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

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

At the individual level.

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

Providing backing by clear architectural decision and business direction

to create psychological safety.

Ensuring there is clear architectural direction plus support from management

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

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

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

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

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

One of the five ideals of software development.

Look at Team Topologies.

A team friendly humanistic approach to software development.

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

The humanist approach to software development is truly

about limiting tech debt.

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

Hopefully I've given you something to think about.

As always thank you for joining me.

And please leave me a review on apple podcasts.

Or wherever you're listening to this podcast.

It's always great to get feedback.

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

review wherever you consume your podcasts.

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

wherever you consume your podcasts.

This is a one man production.

And I live for your feedback.

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

You can also find me via CTO problems.com.

Also a quick plug for my workshop in mid January, 2023.

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

and tech debt from a coding perspective.

It's hands-on it's free.

And you can sign up by the link.

I will leave in the show notes.