The practices that we use are often known as "the intangibles" of software delivery because from an outsider's point of view, they aren't visible as part of the features we deliver but they have the potential to help us build a much better product. 

"Building the thing right" means a focus on crafting our software.

"Building the right thing" means focusing on getting good outcomes for the customer. 

Unfortunately, sometimes the bias can be towards the latter, the pressure to deliver often being greater than the desire for quality.

Poor quality manifests itself in a few ways: poor performance (slow), doesn't work as expected, takes forever for the team to make requested enhancements, and so on. As a customer, this may only be something that you become aware of after being on the receiving end of poor-quality software. 

An incremental approach should help relieve the pressure on the team to deliver. A customer will likely be less nervous about what their money is being spent on if they can see and give feedback on the software. If the customer can use the increments provided so far, it's a win-win.

And although it may seem counter-intuitive, focusing on quality and adopting practices that build it into our software from the beginning will speed up delivery. Why? Because we avoid accumulating something called technical debt.

We first mentioned technical debt in Chapter 1, The Software Industry and the Agile Manifesto, when discussing the Agile principle continuous attention to technical excellence and good design enhances agility. We defined it as follows:

In his blog post Refactoring - Not on the backlog! (https://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/), Ron Jeffries compares software technical debt to the thickets and bushes that might crop up in your previously well-tended field. When you first started out writing software it was fast and easy, just like when you first started mowing the field. We didn't always take the best or straightest path, and in our haste to get the job done, we probably neglected consistency. But when the field was green, we didn't need to think about things like that.

In his blog post, Ron visualizes it something like the following:

Over time, areas of our code get little neglected and small bushes start to form. One day, we find that we don't have time to remove the shrubs, so we begin to mow around them. This is similar to parts of our code that we find hard to maintain.

Instead of tackling the problem head-on and fixing the code, which would slow us down, we go around it, for example by creating similar code that does a slightly different job. The field starts to look like this:

Soon, it gets harder and harder to navigate the area as the bushes get bigger and more numerous. It takes longer and longer to mow the field; at some point, we may even give up trying to mow it at all, only going into that area when we have to. We start to think of this code as "legacy" and consider ways we can replace it. Sometimes, it's just easier to blow it all away and start again:

All of the practices that we describe in this section are aimed at preventing those thickets and bushes springing up in our software. If we maintain a disciplined approach to building software using these techniques, it will ultimately speed up our delivery, increase our agility and our product's medium to long-term viability.