Trust Driven Development
Minimum price
Suggested price

Trust Driven Development

About the Book

Trust Driven Development is about the profession of building successful software. It talks about about planning for change, about process, and above all, about trust.

Process is what we do to make sure that everybody on a project has a shared sense of state and of goals. Trust is what happens when we match that shared state and meet those goals.

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 the sprit of collaboration and not fighting over blame.

Bad process and a lack of trust cause real difficulty in projects and make developer and customer lives more painful. It can be better. This book can help.

  • Share this book

  • Categories

    • Software
    • System Integration
    • Computers and Programming
  • Feedback

    Email the Author(s)
  • License

About the Author

Noel Rappin
Noel Rappin

Noel Rappin is the Director of Development at Table XI. Noel has authored multiple technical books, including "Rails 4 Test Prescriptions", "Trust-Driven Development", and "Take My Money: Accepting Payments on the Web". Follow Noel on Twitter @noelrap, and online at

Table of Contents

    • A Fable About Trust
      • Trust Driven Development
      • Back to the Mechanic
      • Project Zen
      • Where to?
  • I Before You Start
    • 1. What is a Project?
      • 1.1 What is “Process”
    • 2. Who are the Players?
    • 3. What do I Need Before I Start?
      • 3.1 Sharing Knowledge
      • 3.2 What to Share?
    • 4. What prevents sharing?
    • 5. What do First Meetings Look Like?
      • 5.1 Getting the initial feature list
      • 5.2 Workflows
    • 6. Initial Estimates
      • 6.1 Let’s talk about #NoEstimates
      • 6.2 Making story lists and estimates
      • 6.3 Converting the list to something resembling an estimate
    • 7. What do Clients Need To Know?
      • 7.1 Okay, so what’s the problem…
    • 8. Iteration Zero
      • 8.1 Setting up Environments, Continuous Integration, and Continuous Deployment
      • 8.2 Team Agreements
      • 8.3 Spikes and Technology decisions
  • II Iteration Heartbeat
    • 9. Iterations
      • 9.1 What’s an iteration?
      • 9.2 Why Iterations?
      • 9.3 What happens in an iteration?
      • 9.4 How long should an iteration be?
      • 9.5 A Quick Plea About Days of the Week
      • 9.6 The Iteration Planning Meeting
      • 9.7 Iteration process smells
      • 9.8 When don’t I need iterations?
      • 9.9 When should I worry?
    • 10. Retrospectives
      • 10.1 When
      • 10.2 Who
      • 10.3 How
    • 11. Where Do Stories Come from?
      • 11.1 What makes a story?
      • 11.2 Lifecycle of a story
    • 12. Estimation and Velocity
      • 12.1 The Rules
      • 12.2 Why Estimate?
      • 12.3 What are you estimating?
      • 12.4 One Plus One Equals Three, or Point Math
      • 12.5 Validating Estimates
      • 12.6 Estimation in Context, or Estimation in Conflict
      • 12.7 Should You Estimate Bugs?
      • 12.8 Why does this work?
    • 13. Responding to Change
      • 13.1 What’s a change?
  • III Daily Heartbeat
    • 14. Daily Stand Up
      • 14.1 Build A Better Standup
      • 14.2 Date and Time
      • 14.3 Who attends?
      • 14.4 The Virtual Standup
    • 15. Doing The Work
    • 16. Pair Programming vs Code Review
      • 16.1 Effective Pairing
      • 16.2 Code Review
      • 16.3 Code standards and documentation
    • 17. Remote Work
      • 17.1 Set up communication early
      • 17.2 Conway’s Law, Remote Teams, and You
      • 17.3 Split Sites
      • 17.4 Remote Meetings
      • 17.5 When Not To Remote
    • 18. Release Management
      • 18.1 Code Freeze
      • 18.2 Release cutover
      • 18.3 Staging “plus”
      • 18.4 Feature block
      • 18.5 When to deploy?
    • 19. Testing
      • 19.1 When to Deploy to Stage
      • 19.2 When to Deploy to Production
    • 20. Bugs
      • 20.1 Building Trust Before Bugs Happen
      • 20.2 Building Trust When Bugs Happen
      • 20.3 Fixing Bugs
      • 20.4 Bug or Feature?
      • 20.5 Flavors of bugs
      • 20.6 When Bugs Get Serious
  • IV Crunch Time
    • 21. Crunch Time
      • 21.1 The End Game
      • 21.2 Attention Must Be Paid
      • 21.3 Deadlines
      • 21.4 End Game Review
      • 21.5 Code Freeze is never a freeze
      • 21.6 One More Thing
      • 21.7 Continuous Crunch
      • 21.8 Plan for the End
    • 22. Responding To Problems
    • 23. I made a mistake
    • 24. Professionalism in a Hostile Environment
      • 24.1 I think what you are doing is a bad idea
      • 24.2 The project keeps changing
      • 24.3 Scope Creep
      • 24.4 The client has unreasonable time and scope expectations
      • 24.5 I way underestimated this feature/project
      • 24.6 People on this project are not executing
      • 24.7 I don’t have agency, the team is too big
      • 24.8 I’m having personal issues with the client
      • 24.9 The client hates what they said they wanted
    • 25. End of Life
    • Colophon
    • Acknowledgements
    • Changelog
  • Notes

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

80% Royalties. Earn $16 on a $20 book.

We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub