So the concept that we talk about a lot from the perspective of modern software engineering that enables you to push quality, build quality, build security, build these things in from the beginning, build it in rather than testing it in later, is the concept of shift left.

Moving quality assurance earlier in the development cycle. Now shifting left is often controversial because when do you stop? How far left should you shift? As far as I’m concerned, it’s all the way to the left. The people writing the code should be the ones that are writing the tests. They should be the ones that are running the tests, that are taking the fallout from the tests, that are all the way through to, “I need to support this.” If I wrote the code, I need to support this in production.

Now usually in bigger products, that’s team-based, right? So the team that’s working on this feature or this capability or this part of the product, this area of the product, are the ones that also support it in production. But I don’t just mean support it in production. They’re dealing with the bugs, they’re dealing with almost with the support requests. It’s probably being, in a big organisation, it’s probably being filtered through some kind of levels in a centre, but they need to handle those support requests and they need to look at the telemetry for the experiments that they’re doing and figure out whether their experiments are successful, whether things are right. Do we have the right alerts to know when something’s gone wrong with this feature or capability?

That is all shifted left to the engineering team that is building the product. They are building it, running it, supporting it, maintaining it, validating it going forward into the future, which means you need all of those skills that in the past you maybe had dispersed around the organisation. You need all of those skills on the engineering team.

So usually, you have a lot of people who can code, right? But you also have people who have security expertise, who have testing and validation expertise, who have user experience expertise. All of those things move further towards the source of all of our problems and all of our successes, which is building the code.

In the modern engineering space, in agile practices, there are a bunch of tools and techniques that have kind of grown in that space to be really popular, but also very contentious because people don’t want to put in the work because they’re more effort to do right. So it seems like we’re going to deliver less stuff because we’re spending more time on the engineering space. But because we don’t have that arc, or I don’t have, is probably too strong, we have less of that arc of people finding problems in production.

We have less of that arc of reduction in brand. Everybody’s losing their mind because we’re not being presented well in front of our customers. We have less of that. We have an opportunity here to do stuff, but we need to fix this stuff first because we never fixed it before. We just pushed it out and we didn’t bother with it. All of those things are more effective.

Therefore, when we start shifting left and we’re doing more things from the perspective of the engineering team, it takes longer to do each thing the first time, but each thing is done more right. Because the lack of doing things—I’m trying to avoid the term technical debt because I’m including more things in this story than just technical debt—are poor engineering practices and poor quality output, right? For whatever reason, including technical debt is an exponential problem, not a linear problem.

Think about if you built the first story of a building with substandard materials, and then you built the second story of a building with substandard materials. How far are you going to get before the building collapses? Right? Now we have an advantage in the software industry that we can build the first level. We can build the first level of the building quickly, and when we go to build the second level of the building, we can go back and refactor, redo any of the things that we need to enhance the support of the second story of the building, right?

This is a terrible analogy, but it’s working for me just now. It enables us, as you don’t know how many stories your building’s going to have when you’re doing software engineering. If you want to look up the building analogy, look up the Chrysler Building and how the Chrysler Building was built because it was effectively built in an agile manner. They didn’t know how many stories they were going to put on it. They didn’t have all the materials up front. They didn’t have a plan up front of the building and what they were going to do.

It’s a great example of this in that physical space, but in the virtual space, we can do test-driven development. Test-driven development is not about building better code; it’s about having better architectures. We create better architectures because we only create what we need to support the things that we need it to do.

Doing pair programming means that we’ve got more eyes on the code. It feels like it’s going to be less productive, but productivity is not a moment in time for the engineering team. It needs to be looked at across the whole system. We can take what seems like a hit on productivity to do pair programming because there’s two people doing things. Why can’t we have them both doing their own thing? But we have less problems that we need later, which are much more expensive than the pair programming is at the start, right?

Same with test-driven development. We build better architectures, so it’s easier to add stuff going forward into the future. And when we do need to refactor our architecture, we have a test infrastructure to validate at each change as we make it to make sure that we’re not breaking existing things, existing stories that are supposed to happen.

These tools are fundamentally part of that story of how do we build a practice of engineering excellence within our organisation and enable great things to happen. We want to build great products. We want to make great profits from the great products that we build, and the only way we’re going to do that is if we do things in a way that enables us through the future rather than us getting to a point where we’re drowning under the weight of all the crap that we’ve shipped to production over the years.

And if you are currently drowning under the weight of all of that, as the Azure DevOps team was when they moved from their waterfall model that they’d been doing for 200 what let C to the for five years, and then they moved to continuous delivery to production, they had to go pay back all of those loans that they’d taken out for the future, right?

But what they found was that in paying back those loans, they became so much more effective because of the exponential cost of taking out those loans. They became so much more effective that in actual fact, the cost of paying it back was completely irrelevant to the benefit and value that they got from it being paid back. That makes sense, right? They went from 25 features to production each year with the same number of people to nearly 50 features to production each year.

And even taking four years to get there, holy moly, I would rather have 800 features than 25 features, right? And yes, the features are smaller, but it’s more experiment, right? It’s more chances to get something right. It’s more ideas to see if they connect with the customer.

So in the old ways, you have to stick with and focus on something even when it’s not quite the most optimal thing. But if you’re doing lots of little experiments, you can find, “Oh, this thing resonates really much more than these other things with the customer. Let’s do more on that until it stops resonating,” and then we move on to something else and move on to something else, and we build a better product with more capabilities.

So there are lots of tools and techniques that you can use within the context of modern software engineering practices to build quality in from the start and enabling your teams to be as effective as possible to choose the practices because they need to be able to choose the practices that work best for their context. That’s something that naked agility can help you with.