Agile Thinkers

Jared Richardson Q1

Jared Richadson is co-author (with Will Gwaltney) of one of my favourite software development books - Ship it!.  Just a couple of weeks ago I gave away a copy of Ship It to a client but - to be honest - I am hoping they don't read it.  If they do then they may not need to use me so much ...

Here's Q1 - Hey Jared, I thought Ship it! was a real keeper.  I've recommended it to many of my clients and friends. Tell me a bit about yourself - both your personal life (if you don't mind) and your professional life.  What makes you tick?

Let's see... big picture first. I'm married to a beautiful girl I met in high school, but couldn't land a date with her until I was in college. Not quite a high school sweetheart, but close. We have two daughters, ages 4 and 9. As Andy Hunt recently told me, it's not the time that kids take, it's the bandwidth. We live in Morrisville, North Carolina, which is in the middle of Research Triangle Park. We sit in the middle of the Raleigh-Durham-Chapel Hill area, which is to say, near the Duke Blue Devils, the University of North Carolina Tar Heels, and the North Carolina State University Wolfpack. Basketball country.

Both personally and professionally, I'm a tinkerer. I don't like being locked into a single task or job.

I've built water-cooled computers (from components, not kits), including an evaporative cooling tower. :) I'm running OS X, Kubuntu Linux, and Windows XP in my home office. I've got a MythTV box that's very close to pushing out the satellite dish. I have a canoe and a kayak that don't make it into the water very often. A few years ago I  wired my generator into my house's electrical circuit. I blew out a few appliances in the process, but that's another story. :) The lights over the kitchen table blowing out were spectacular!

After two years of consulting I joined a startup and I'm loving it. I get to tinker with architecture, write marketing literature, help with GUI redesigns, and sit in on sales calls. I've written Ruby code, set up Java application servers, and so on. I enjoy being at a small company where we all get to wear multiple hats.

What makes me tick? A problem I can immerse in for hours or days. When I'm working on this type of problem (right now I'm trying to find a completely different way to present the information our product collects and generates), I need to have dedicated time to dig into it, consider it, and bounce around different alternatives. I'll research alternatives on the web, scribble on white boards, mind map ideas on legal pads, and so on. I like to pull in other people to brainstorm and bounce ideas off of them... then I step away to another problem and let the first problem soak... (probably ferment!). But I keep coming back to the original problem. It always takes me longer than I want to solve these types of problems, which is frustrating, but when the problem is solved, it's very satisfying.

So I guess I'm task-oriented. I like a problem to solve.

I also like stepping back to see the bigger picture. I like to understand what the pattern is and why the problem occurred in the first place.

If we have to work overtime for weeks to get a release out the door, why was it that painful? We had no continuous integration system or test automation in place, so the product drifted into a brittle state. We spent too much time verifying our changes hadn't broken anything instead of adding new code.

Spotting (and fixing) these types of organizational patterns is what motivated Ship It! in the first place. It's really a book about these types of patterns you can use to map out your software shop. The startup I'm at (http://6sa.com) is gathering metrics about the way developers and teams work to spot some of these problems automatically. That's been an interesting challenge.

Jared Richardson Q2

Q2 - Tell me about the experience of writing Ship it!

Writing Ship It! was hard. Andy Hunt lives nearby and Will and I met him for lunch to pitch the idea. At the time I had a number of half- written articles on a Wiki that I was sure I could string together into a book in a month. Two months at the outside I told my wife. I think the book idea was the first one Dave and Andy accepted for the Pragmatic Publishing line (outside of their own books)... Mike Clark was right in there though. I'm not sure who actually signed papers first. But it took us a year and half to finish Ship It! My wife still reminds me that I thought I could finish it in a month.

The first problem we had is neither Will or myself had even written professionally before. We were developers. We thought we could write, but we couldn't. Andy invested a lot of time into us as not only an editor, but a writing coach. Being one of the first authors on the label has it's advantages. I doubt Andy would have time for authors like us today. But it paid off. Ship It! turned out very nicely and has been translated into Japanese, German, Korean, and even has an India sub-continent version.

The inspiration for the book is another nice story. I was having lunch with a friend and he was telling me about a project that was having problems. A short lunch stretched out well over an hour while I started scribbling out ideas on napkins for him. The topics ranged from the proper use of source code management to tracer bullet software development. Will and I had been lucky enough to work at two startups with very little process in place, so we (along with another developer named Jim Weiss) got to bring in the process. We had to gather (or generate) the ideas, sell them to the developers, then make them work. And this was the information I was sharing with my friend.

After lunch I dropped by Will's office and told him we had to write this stuff down. After a few brainstorming sessions we met with Andy, and the next year and half just sped by. :) Actually, there were times it sped by and times that an evening of writing felt like it took days.

The hardest part is not writing new material. The hardest part is going back over what you've written to tighten it up and make it worth reading. Rewriting so someone besides you understands the ideas, removing the 'extra' words, breaking up long passages with stories and humor. After you've rewritten and retooled a section a couple of dozen times, it starts to run together.

It was  great experience though. When I look at what I write now and what I wrote then, I'm embarrassed by what I thought was good writing. I've a few books "in my head" for the next book. I just have to carve out the time to write them. It was a great experience and I plan to write more books.

Jared Richardson Q3

Q3 - Am I right that you used to work for SAS?  If I aren't then ignore ... I've heard some fantastic things about them as a company ... what did you take away from your time there?

The take away from SAS is pretty straightforward. Your people are your greatest resource. If you work hard to keep your people happy and productive, then the software is a by-product. Dr. Goodnight makes it a priority to keep his teams happy and that shows. I worked at the corporate headquarters with 5,000 other people and they had (if memory serves) a 3% turnover. For a software company that's incredibly low. Most people just don't leave SAS. Look at your company's training budget (for new hires) and ask yourself what you could do with that money to keep your existing people to stay around. Avoid having to retrain so many people.

But what you've heard about SAS is true. There were M&M's in the break rooms. The walking trails in the woods are paved. There was an indoor pool (attached to the gym), a daycare (or three), doctors, hair stylists, massage therapists.... I could go on. They try to keep you on campus for things like haircuts and doctors visits. This is a huge convenience to the employees, but it also gets you back at work sooner. Everyone wins.

Q4 - Jared Richardson

Q4.  Tell me about your current venture?  A start-up ... that's a big change from SAS.

The startup I'm at has a very interesting idea. It's about creating an extreme level of transparency and then using that information to measure progress. We look at information from the team's source code management, issue tracker, feature tracker and even the IDE.

At the end of the day I can look at a team and see that they're spending too much time in the debugger, so I can talk about continuous integration and test automation as a way to keep people out of the debugger and in code. Another team might be reading code all day, trying to understand it. Then we talk about the peer code review or pair programming to get training levels up.

We automatically create burn up charts and then use them to teach managers why feature creep is bad. They can instantly see how the team can't catch up with an ever growing scope. Or how the team committed to this feature set but only delivered half of that. Then we pull up a "difference from estimation" report to see which features had bad estimates.

And at every step, because we automatically harvest real data in the background, we've got the actual time spent on each feature. Instead of guessing how much development time was spent over three days, we can say it took 12.74 hours to create that feature.

But this level of transparency scares a lot of people. Our industry has been very closed traditionally. Our managers generally don't understand what we do or how we do it. And as a result, most projects fail. Some from bad estimation, others from bad management. Sometimes it's because no-one realizes there's a problem until too late to help. The last numbers I recall seeing were a 75% failure rate for the industry. We've got to step back and see if we can't find a better way to build software. Many of the agile practices do just that. 6th Sense Analytics makes an amazing amount of information available and we're starting to see some pretty amazing insights come out of that data.

A tool like 6th Sense can be abused by a bad manager and it's a fundamental culture shift for many shops. But on the teams with the courage to make the leap, we've found both development and managers come away with a better understanding of the other does.

Why am I at a startup? If you saw my first question and it's answers, you know I like to tinker. And I get to do a lot of that here. We have working software, but there's still a wide variety of work to be done.

Q5 - Jared Richardson

Q5.  I give your book away a lot.  Tell me about the books you give away or recommend.

Thanks for that! I can't tell you how many times I talk to someone at a conference who came to hear my talk because they were given a copy of Ship It! by a friend or co-worker.

I interact with a broad range of companies and technologies, so my book suggestions vary widely. Here's a quick sampling.

• If you've got someone trying to learn the Java stack, point them at Scott Davis' JBoss at Work.
• Learning Ruby?  Dave Thomas and Andy Hunt's Ruby Pickaxe book and Hal Fulton's The Ruby Way.
• Rails -  Dave Thomas's Agile Web Development with Rails
• Ajax?  Justin Gehtland's Pragmatic Ajax. And the Prag Press has new Prototype and Dojo books out as well.
• Groovy?  Check out Venkat Subramaniam's Programming Groovy
• Grails?  Jason Rudolph's Getting Started with Rails.
• Andy Hunt just released his "Refactoring Your Wetware" book. It's all about your soft skills... the stuff in your head. I think it's something everyone should read.

Q6 - Jared Richardson

Q6.  What surprised you most about other peoples reaction to Ship It!

Two things have surprised me the most. The first is the broad range of reactions. Early in the review process, I got three emails on the same day. The first said "I can't believe you suggest these practices. Everyone already does everything you talk about." The second mail said "The book is too theoretical. The practices are great ideas but no-one actually does these things." The third mail said "Wow! I knew most of these practices, but I've never seen them put together so well. And I needed to be reminded of the ones I knew anyway. Thanks!"

And that sums up people's reactions. Some love it. Some don't. And that's okay. No single book will reach every person. We've reached a lot of people with Ship It! and that feels great. It's now in German, Japanese, Korean, and there's even an India sub-continent version. I get email fairly regularly from people who've retooled some part of their shop's environment around Ship It! It's a great feeling to know you've had an impact on people you've never met.

The second thing that's surprised me is it's sustainability. It's been almost three years and we continue to sell more books every quarter. It's a slow climb, but it's still moving up. We worked hard to keep Ship It! language and technology neutral, and I think it's worked.

Q7 - Jared Richardson

Q7 - Tell me - or really, the folk who've not read your book - a little more about the ins and outs of Ship It!  What's in it for them for reading it?  Who will enjoy reading it?  Who won’t enjoy reading it?

Ship It is our take on the entire software ecosystem. Often a shop that does a great job in many different areas will have huge blind spots. Maybe a team has done a great job at following a process but ignores the infrastructure. Ship It! covers three major areas. Techniques, infrastructure, and process. You can see this in our poster of key practices http://media.pragprog.com/titles/prj/color_poster.pdf.  The book also has a chapter of Frequently Asked Questions that talk about common scenarios you'll run into and how to use the key practices to solve those problems.

But it's not a religious diatribe on "The Right Way" to work. We tried very hard to introduce you to the reasons and ideas around following a process, then we suggest one you can use. I'm more about getting teams to use the ideas than to work like Will or me. We also covered the "what happens when you ignore this area" too.

Who should buy Ship It? The book was written as a guide for developers who wants to make a difference on their team, but it's been very popular with project managers and tech leads as well. In fact, it's often categorized as a project management book. I that's because there aren't a lot of ecosystem books out their and no one knows how to categorize it. :) It's not Java or C#. Must be.... project management!

Clarke: That's my last question for Jared for now.  I've found Ship It! extremely useful and I thank Jared and William (his co-author) for their wonderful contribution.