Noel Rappin Writes Here

Trust-Driven Development Questions You Might Have

Main Page | Read Introduction | Tentative Table of Contents

Q: What the heck is this?

This is a book about projects, process, and professionalism. It’s about the flip side of software craft — being able to apply that craft as part of a group working toward a common goal, and being able to land that project. It’s about working in an environment where you don’t choose all the requirements and all the constraints.

And it’s about that moment when something goes wrong. What happens at that point depends in part on how trustworthy and professional you’ve been to that point.

It think that a lot of developers in rough projects don’t realize or don’t have the vocabulary to talk about why their process is hurting them. I’m hoping to provide that, too.

Q: What’s the pricing and deal?

The book is available at LeanPub's optional pricing for a minimum of $15 and a suggested price of $25. After purchase you will continue to receive updates.

Q: Can I buy It?

Of course: Click here:

Q: Why now? Are you insane?

I’ve wanted to write something like this for years, but was stymied by a combination of “what do I have to say” and deciding to do other projects.

Am I insane for trying to write this while still working on the JavaScript book? Maybe, but the two actually don’t share much space in my brain, and I’m enjoying the idea of finally writing a book where I’m not chasing a rapidly moving library as a target. Expect this book to fill my writing gaps while I wait for Ember to settle down a bit.

Q: Is this an Agile book?

Yes and no.

There’s no question that many, if not most, of the practices that I talk about in Trust-Driven Development are Agile techniques. That’s because — Spoiler Alert — I’ve found those techniques to be useful on the projects I’m working on.

That said, I’m most interested in these three questions

  • Why do Agile techniques like iterations, small stores, and pair programming work for small to medium-sized web projects?
  • Can we infer anything from that to talk about what might work on your project?
  • How can you tell when your process and practices are hurting you and what can you do about it?