Tag: software

Categories
Leadership

Tech Debt

Broken Windows in a Wall
Photo by Tara Evans on Unsplash

Software Engineers talk about Tech Debt all the time, but other than it being a bad thing, they don’t often stop to explain why it’s bad, or why they are going to spend so much time fixing it rather than doing something valuable.

Martin Fowler has some excellent resources that explain this in the words of software systems, choosing to prefer ‘cruft‘ more so than debt. It’s a really strong approach. Debt means different things to different people. In business, debt can be a good thing! It lets you do more now. You claim some of the market, or you grow, and you pay back the debt from excess profits you’ve made. Overall it costs less to take the debt.

Sometimes we squint a bit in software world, take some shortcuts and call it that good kind of debt. Then we take a few more ‘quick wins’, then a few more, until we end up throwing our hands in the air and the Engineers are calling for a re-write.

Instead of that, when we think on ‘cruft’, we can take a more healthy approach. We build the smallest thing we can to service the needs of today. We build it well, and we can change it quickly. Cruft builds up as we learn more, honing what we have to the real needs of the world. Assumptions we made in the past turn out not to be valid, and we need to correct.

By cleaning up as we go we keep on top of things, keep moving fast and keep driving value at pace. If we understand this as cruft not debt, then it’s in the interest of every stakeholder to stay on top of it as we keep going fast by fixing as we go.

Bringing this back to a real world example, I’m busy looking at the windows in my house. Lovely wooden frames, original with real craft put into their creation. However, they’ve not been well maintained. Rather than a quick sand and paint every few years they have been left in the weather for years on end. Patched and painted without repair, then patched on top again.

They look OK from a distance. You could patch and paint again but it’d only cover a couple of years until you need to go again. That’s paying 5x the usual maintenance cost.

You could strip them back fully, repair everything and get into the standard maintenance cycle. That’ll cost most of what a new set will set you back, and they’ll still have some of the neglect baked in.

So you have to take them out, take out some of the supporting sills and lintels that have also been neglected and start again, a big expense but necessary to get a high quality outcome.

Back to software, and you see the same cycle. Build your maintenance in to your plans, fix as you go and don’t let the jobs get away from you. If you have to get something live quickly, then recognise that and double down on improving that area in the near future. Fix a quick fix properly, or it becomes a load bearing layer of your solution.

Don’t accept bad debt and you’ll drive more value faster for longer!

Categories
Coaching Leadership

Dont Innovate to Hit the Date

Person lost in a hedge maze

When we’re building software, we’re creating something new. It’s exploratory, it’s uncertain and it might not work.

Often in the world beyond the tech teams, we think we’re just following a plan to build to a schedule.

The mismatch between the two causes approximately all of the conflict in a software focused organisation.

We use a lot of techniques to bridge the gap, all loosely badged under the Agile heading. Basically, we always endeavour to have working, shippable software that we can show to people, and we always complete the most important things first. That means we can launch the software on any given day, and it’ll have the most vital pieces.

Engineering have the power to solve problems, stakeholders have the power to decide if their problems are solved enough or not. So when we work in this way, everyone gets their key pain points addressed, and everyone is happy.

This works best when we’re working in an incremental problem space, building out a product that provides benefits with some features, and will provide more as those features are added to and refined.

Sometimes we’re not in that space. Instead we’ve got to hit a fixed date. We know what we need to and we know when we need to do it by. When the date is truly fixed, it’s usually due to some sort of regulation, so there’s the added spice of needing to be compliant with some law or face a penalty.

In this scenario, we need to strip back some of our exploratory instincts and move more towards the schedule model. Nevertheless, we must also keep in focus those agile principles of solving the most important problems with always shippable software.

Rather than innovating, we make sure we hit the date:

  • Pick known technologies
  • Extend solutions that work today rather than starting from scratch.
  • Choose the approach that has least work
  • Sequence your plan to get to done sooner
  • Allocate additional resources

When we know what we need to do, we are following a map along a known route rather than exploring the territory.

Measure your progress, correct your course when needed, and don’t innovate to hit the date.

Categories
Leadership

Building to Schedule

Photo by Mark Potterton on Unsplash

There’s a common mistake in the thinking of people outside the immediate world of software, and that’s in thinking that it’s a predictable and repeatable process that should be easy to plan.

The comparison that is made is usually towards building houses or something similar. We’ve spoken before about the creative endeavour of software, and about how house building might not be as easy as it seems from the outside. Today I’ll look a little bit more at that.

Across the road from me is a brand new theatre. It’s probably about 60-70% complete, and I’ve been able to watch it take shape over the last year or so. In it, I can see a lot of familiar activity from software development, writ large on the physical world.

It’s particularly relevant as it’s a unique construction. It’s following a plan, but it’s clear that there’s learning and refinement going on all the time. I’ve watched walls go up to be covered in insulation, that’s been inspected, taken down and redone. I’ve seen windows being put in whilst other trades are forced to stop their work to let the glazers past.

There have been days when the main activity is inspecting what’s been put-up, which has again led to rework and changes.

It’s not a simple linear progression of steps, it’s a cycle of work, review, pass / fail and rework or move on.

It’s clear that this distance from the linear progression is even more pronounced due to the unique nature of the building. It’s big and complex, and it’s not the same as anything that’s gone before.

That’s exactly what we get in a software product. Big and complex, a unique creation and something that needs to show learning as you go.

So if you are struggling with someone who thinks it should be an easy task of following a plan step by step, show them someone putting up a complex landmark building to open their eyes to reality.