Trust-Driven Development Introduction
The Parable of the Auto Mechanic
You go to the auto mechanic. Maybe it’s just an oil change. You aren’t expecting anything else.
You are in the waiting room, avoiding the coffee and with your headphones on to drown out the local news playing on the TV. The mechanic comes to get you, with a grim look and some props.
“It’s like this,” the mechanic says. “Your brake pads are wearing down. Could last a year, could fail on your way home. That’s $500 to fix it now, but if it fails on the road, then things might seize up, and you could be looking at $1000 of dollars of repairs.”
The mechanic shows you the props: one new looking break pad, one scruffy looking one (not yours, but one in a similar state of disrepair).
What to do? Failing break pads certainly sound bad. If, of course, they are really failing. The mechanic certainly could be lying to you to get you to buy $500 worth of unneeded brake pads. Sitting there in the waiting room, you have no way to evaluate the mechanic’s claim.
It’s a matter of trust.
What do you do? More to the point, what criteria do you use to even make the decision? Even more to the point, what can the mechanic do to convince you that the work is necessary and correctly priced.[^1]
Trust Driven Development
Hi, I’m Noel Rappin, and this is a book about building successful software.
There are a lot of books about the craft of building successful software. These books talk about writing tests, building clean code structures, about code simplicity and maintainability. This is not one of those books.
This is a book about the profession of building successful software.[^2] This book talks about writing user stories, about planning for change, about process, and above all, about trust.
At some point in your software project, something will go wrong. There will be a miscommunication, or a sudden change of requirements. You might even make a mistake. What happens then depends on a lot of factors, some of which are outside your control.
One factor that is in your control is whether you’ve presented yourself as worthy of your partner’s trust so that rough spots along the project path can be approached in sprit of collaboration and not fighting over blame.
Back to the Mechanic
With that in mind, let’s go back to the mechanic.
Here are some of the factors that might matter for your decision:
- Does the problem seem plausible? Maybe you’ve noticed brake problems. Maybe your car stops on a dime.
- Does the prices seem reasonable? If the last time you had brake pads replaced it only cost $200, then you are going to be skeptical.
- Similarly, you’ll probably be more skeptical in general the higher the price is.
- Have you had past dealings with this mechanic, positive or negative?
- Have you had past dealings with other mechanics, positive or negative?
- Do you have a way to independently verify the price or the need?
- Does the mechanic have an unusual financial incentive to make stuff up?
On the mechanic’s end, there are trust-improving steps that might be taken:
- Offer a warranty of some kind against work mistakes.
- Offer to show the driver the actual bad brake pad.
- Act professionally and honestly in previous dealings.
- Offer economic incentives that show that you are more interested in long-term customer happiness rather than this one payday.
Before I beat this point all the way into the ground, I hope you see where this is going.
As web development professionals, most of us are the mechanic in this situation. We are attempting to explain technical details that may be not-obvious or counter-intuitive to the customers of our work, and trying to do so in a way that is clear and honest.
We’re also trying to do this in the context of a project — a series of technical decisions that lead to a particular goal. In order to reach that project goal, we have a process. For our purposes, “process” is any task we do to communicate the state of the project to other members of the team. More on that definition in a bit.
In order to reach our project goal successfully, input and feedback from people outside the development team is vital. It is our responsibility as technical professionals to communicate project status and project risks clearly and accurately. I shouldn’t need to know the details of how brakes work to talk to my mechanic, and my clients shouldn’t need to know how a Ruby interpreter works in order to talk to me.[^3]
We spend a lot of time talking about software craftsmanship in terms of the quality and maintainability of the code we write. I want to look at other aspects of professionalism — the ability to communicate our work to others both inside and out of our team, and the ability to guide a project to completion against uncertainty and pressure.
When we get the communication and guidance wrong, it leads to real pain. Incorrect work, work that does not meet the customer needs, work that is not flexible against the kinds of changes the customer will face, work that suddenly needs to be fit inside an impossible deadline. When there is no trust between the players on a process, then time is spent verifying and validating work far beyond the actual need. When people spend time worried they are going to be blamed, they don’t do their best.
Projects and Trust
While most of the practices and principles expressed here are consistent with various Agile software methods, I don’t consider this a book on “doing agile”. Instead, I see this book as more of guide for those in positions of technical leadership for making projects work. A fine distinction, perhaps, but it makes perfect sense in my head.
Many common agile practices are fantastic tools for building trust among a product team, but I don’t want you to come away from this book thinking that any specific tool or practice is necessarily the right tool for your situation. I would like you to come away from this book being able to recognize the painful parts of your process and having some tools for improving them. I’d also like you to come away with more proactive ideas about what makes projects successful and how that applies to your situation.
Honestly, if I can just get you to stop estimating in hours, I’m happy — that’s just a bad idea all around.
There are about six or seven ideas about how projects fit together that I really believe, and which guide most of the more specific suggestions in this book. We’ll expand on most of them as we go.
- If the developers and business unit trust each other, you can get away with almost any process. If they don’t, almost nothing will help. How do you build trust?
- You always do all the steps. It’s best if you do them in the right order.
- The goal of having a process is to ensure that everybody involved has a common understanding of the state of the project.
- The right amount of process on a project this size is a little bit less than you think. Meaning that the problems you will have from slightly too-little process are more manageable than the ones you will have from too-much process.
- The developer’s job is to determine cost, the customer’s job is to determine value.
- You will never know less about your project then you do right now. Why would you make binding decisions now? Preserve ambiguity.
- Good project practices don’t just happen. They need to be maintained and seen publicly to be maintained. The “broken windows” theory applies to projects.
I hope you’re with me. Let’s go…
[^1]: Assuming, of course, for the sake of argument that the mechanic is a professional and the work is actually correctly priced…
[^2]: Okay, there are a lot of those, too. Work with me.
[^3]: If I do know a little bit about cars, then bonus! If I think I know more about cars than I really do, that’s a problem.