We have met two of Matsumoto “⁠Matz⁠”⁠ Yukihiro’s favorite authors: Bruce Tate and Chad Fowler. Now, meet their publishers. Andy Hunt, along with his business partner and co-author, Dave Thomas, is the force behind The Pragmatic Programmers, “⁠an agile publishing and training company.⁠”⁠ The term “⁠agile⁠”⁠ is no coincidence: Hunt and Thomas were among the signers of the Manifesto for Agile Software development. They are also known for their own book, The Pragmatic Programmer: From Journeyman to Master--which maintains that programming, first and foremost, is a craft, and therefore worthy of a serious, lifelong commitment. Thomas and Hunt wrote the definitive English-language guide to Ruby development--known widely by its informal title, “⁠The Pickaxe book.⁠”⁠ Chad Fowler collaborated with them on version 2.

We begin with Andy Hunt, a man who is neither shy nor a man of few words. We’ll meet Dave Thomas next month.

What’s your background?

I got interested in computers when I was a wee lad and the 6502 microprocessor came out, along with the 8080 and z80. On my first computer, I paid extra to get 48K of RAM, which came on four, hand-soldered, 11x14 inch boards. The memory required two extra fans--for just 48K. Now I regularly get email from people where their signatures are larger than that. I started programming in middle school, got a degree in computer science from Georgia Tech, and worked my way through college programming and consulting.

In the mid-90s, I left the corporate world to go out on my own as a consultant. That’s when it really started to get interesting, because along the way I met Dave Thomas. We noticed that our respective clients were falling into some of the same and common traps of that time. And we decided that our respective ways of doing software development, which were remarkably similar, represented a better approach. So we cobbled together a white paper to give to our clients to get them started on the right foot. That little white paper grew until it became The Pragmatic Programmer book, which came out in 1999. To our amazement, the book hit the top 10 on Amazon.com. That started the ball rolling, and the book continues to do well even though it is a decade old.

Meanwhile, I was working on a beta project, where the clients were fiddling on the fly with algorithms and procedures. So I needed a development tool that would easily do rapid prototyping. I wanted it to be fully object oriented and have good low-level access to the operating system. I couldn’t find anything, so I ended up writing it myself in object-oriented Perl, which was even more painful a process than it sounds. But eventually, Dave sent me a link to Ruby on Matz’s site. At first look, the language didn’t obviously suck. And as I played with it, I saw that Ruby was in fact a nifty little language that actually met my criteria. That led us to write another book, and what started as a short reference guide to the Ruby programming language eventually came out to more than 500 pages: the first book outside of Japan to talk about Ruby. The market in the U.S. at that time was about six programmers, so the first edition didn’t do terribly well.

In 2003, we started the publishing company, trying to get books out there that we wanted to read, that we thought would be helpful to developers. That has always been our mantra and has served us well. We ended up getting the rights back for the Ruby book; Dave bumped it up to 600-700 pages. Then Ruby 1.9 came out later, and that version of the book exceeded 800 pages. It’s a doorstop, but it’s the bible--the one you go to for Ruby.

We wrote other books for our Pragmatic Bookshelf series--related to agile methods and just plain, common sense pragmatic programming. The first three books were on unit testing, version control and automation. We looked at these as a good foundation no matter what technology you use. They are the hygiene layer―the brushing-your-teeth and flossing level of software development. Then we added in all the other cool technologies that struck us as time went by―Ruby on Rails, Erlang, Clojure, etc. That brought us to where we are today, a tech powerhouse of a publishing company that gets almost embarrassing love over email, Twitter and reviews.

Was the Agile process in your mind when you wrote The Pragmatic Programmer?

Absolutely―everyone involved at the time was seeing the same types of project failures and challenges. There was this big hope that upfront design would solve everything. You’d get everything nailed down ahead of time, figure out what the program should do before getting all those “⁠whacked-out⁠”⁠ coders involved. The coding, when it came, was almost an afterthought.

The problem is that this approach doesn’t work. I remember an early client, the chief architect on a very large project, who literally papered the walls of his office with static class programs. That reflected this prevailing idea that all you had to do was specify everything in the tool, hit the button, and the code for the whole project would be automatically generated. My client’s team worked on it for almost three years--and never produced a lick of running code. The project ended up being cancelled. We later read that the company took a $14 million charge against earnings on this particular project.

What was the lesson learned?

That you can’t fully nail down the requirements up front. That’s because users generally aren’t particularly clear on what they actually need. Steve Jobs knew that. He didn’t ask users what they wanted; he gave them what they needed. There’s also another variable, sort of a rough corollary to the Heisenberg uncertainty principle: when you introduce new software into an environment, it alters that very environment--so the needs keep changing.

Agile’s answer to this is fast iterations: get user feedback over days and weeks, not months and years.

That’s especially true when you look at what Internet time has done to our sense of the pace of change. Now, no one in their right mind does a software project that way. Can you imagine telling a client: “⁠give us the requirements now, and we’ll see you in three years with a product?⁠”⁠ Entire industries could rise and fall by then. And of course SaaS [software as a service] has dramatically changed the cycle. So old ways of thinking and old tools aren’t going to cut it. You have to go with fast iterations, and with a safety net of unit tests--testing a small piece of the application--so you don’t fall on your face in front of those 50,000 new users you just brought in.

But what’s ironic is that we haven’t been agile in adapting the agile principles, themselves. Over the last 10 years, people have rigidly adhered to particular agile practices, such as pair programming and test-driven development. They are undoubtedly getting some benefit out of that, which is dandy--but it is not what agile is all about.

The book “⁠From Novice to Expert⁠”⁠ by Dr. Patricia Benner talks about how folks--nurses, in her case--attain and grow their skill set. She writes that novices inevitably start off with simple rules they can follow. But to grow into experts, they must go past that. She said that “⁠practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time.⁠”⁠ That is the heart of agile. Whatever you are doing, whether it is a standup meeting or test-driven development, it needs to be revisited, tuned and tweaked for your particular context. Alastair Cockburn has said for years that each project needs its own methodology because every project is different. There is a lot of truth to that, and it is something we’ve forgotten. We take the handed-down wisdom of just do these practices and you’re doing XP [Extreme Programming]. But that wasn’t really the intent. That was just to get you started.

So the Agile Manifesto just a starting point. Your group never meant it to be dogma.

Absolutely: 2011 was the 10-year anniversary of the manifesto, and I was looking through notes from that original meeting. A couple of things jumped out at me. When the 17 of us got together, we really didn’t spend any time talking about individual practices. We figured this was just a starting point, and that we would see hundreds or even thousands of new methodologies spring up that would be vaguely agile in nature. Every consultant worth his salt would come out with his own methodology, practices, tweaks and adaptations, amounting to an explosion of new ways of developing software.

It didn’t happen. Maybe it’s human nature. Despite what we claim, people really like to be told what to do with the promise that it will work. We like repeatability. We like formulas. But every project is different and you are different―you are a year older, your team has a year more experience, technologies have changed, your users have changed, and the world has changed. As Heraclitus said: you never step in the same river twice.

If you are serious at adopting an agile approach, you need to look at some existing system, say XP or Lean or Scrum. Look at the problem it is trying to solve and how it goes about solving it. Then consider: do we have that same problem, and will this solve it for us? Or do we need to make some modifications? Of course, if your team has never done agile before, you need a coach or a consultant with real experience to help you through the process.

You and Dave Thomas describe The Pragmatic Programmers as “an agile publishing and training company.” What do you mean?

Where agile methods make sense, we apply them. We use the same processes, like short iterations and constant feedback, and some of the same tools, like version control. We have a build machine in the background that continuously builds books in development so you can see the results of what you are working on as you go along. It turns out that writing a book is a lot like writing software. You are creating something. Of course we don’t have a compiler, so we need a person to make sure you have your references, that you’ve declared all your variables and that the flow makes sense. We can make changes quickly because all our authors check into a common version control system we know what their progress is. We have a wealth of data we can mine that other publishers have none of. They have to re-key books and errors can creep in. Our authors write in an xml derivative and are able to include code live off the disk.

When I wrote Practices in Agile Development with Venkat Subramaniam, we needed a definition for agile. Well, there wasn’t one that anyone agreed on so I came up with: “⁠agile development uses feedback to make constant adjustments in a highly collaborative environment.⁠”⁠ I think we’ve shown that that principle can be applied to any business that wants to be successful in the 21st century.