I’ve been listening to the Ruby Rogues and, on Episode 204, they had Dave Thomas on as guest. He was talking about Limerence and I was instantly hooked. The episode was really interesting, especially the way Dave presented the material. His views on programming languages and tools just blew me away, so I looked into more of his work. It was then that I realized, that this was the Dave Thomas who wrote “The Pragmatic Programmer” and “Programming Ruby” and cosigned “The Agile Manifesto”.
Recently, I was lucky enough to interview him. Take a few minutes to learn more about this extremely influential developer and writer.
Q: For the few people that don’t know you, could you tell us about yourself?
For people that don’t know me, I’m a young and incredibly attractive global adventurer, with a string of PhDs and world-changing inventions to my name.
For the people who know that’s not true…
I was born in England, and spent my childhood in the UK, Canada, and the US. I did my secondary schooling in England. Over there, there were a series of tests you can take called A-levels. I took some a year early. Once they were finished, the school ran out of things for us to do, so they sent us across the road to a local technical college. We took the very first Computer Science course, and I fell in love. Before then, I was going to do math or physics, but once my first Basic program said “Hello, David” I knew that I’d have to find a computing degree. In the end, I went to Imperial College in London and loved every minute (apart from statistics).
Once I graduated, I worked for many years for what would now be called a start-up. I was their first employee, and learned my craft on a wide variety of different projects, from low-level OS development to writing the runtime for a COBOL compiler. I played in a lot of industries, with a lot of languages and operating systems, on three continents.
I then started my own company in the UK. About five years in, I was on a project in New York, where I met the woman I married. She came back to the UK for a further 5 years, and after that we moved to the US, where I now live.
About 17 years ago my business partner, Andy Hunt, and I wrote The Pragmatic Programmer, which changed our lives. Because of the success of that book, we became involved in the writing of “The Manifesto for Agile Software Development”, and we got invitations to speak around them. Since then, things have just grown. We have a successful publishing business, and I think it is fair to say that we have helped launch a number of world-changing technologies using it.
Q: What language do you use, and why do you use it?
I use many languages, depending on the work I’m doing. Today, for example, I’m writing Ruby code as I’m doing some work on pragprog.com, our online site. It’s a large (80+kloc) suite of Rails apps. Last week, I was writing Elixir code, because I wanted to experiment with some of the ideas behind microservices.
Languages are tools, and you should chose them the same way you choose any tool. Is it appropriate for the job you’re doing? Does it look like it will last? Will it enhance your performance? And does it fit your hand?
The latter point is an important one that is frequently overlooked. If you are going to be using a programming language for 8 hours a day, 5 days a week, then you’d better be comfortable with it, otherwise your life will just be a struggle.
That’s one of the reasons I first started using Ruby—it made me happy when I was coding in it.
Q: You are the the original signatory and author of the Agile Manifesto. What was it? How has it changed the way we write software?
Back in 1999, software was in a bit of a mess. People were either using large, rigid methodologies for creating their systems or, more likely, they were using no methodology at all, and hoping that wild, random hacking would see them through. Project success rates were low, as was developer morale.
During that time, a number of people were experimenting with alternatives. Kent Beck was exploring his ideas of eXtreme Programming at Chrysler, Ward Cunningham was building a community around the C2 wiki, and folks were trying Scrum and other simpler methodologies. A group of 17 of us got together to discuss what all these approaches had in common. We discovered this could best be expressed in terms of our values—what we felt was important when developing.
We published the 4 core values as The Manifesto for Agile Software Development, and created a website where people could register their agreement.
For many of us, that was the end of it. We didn’t want to create methodologies or tell people how to do things—we just wanted to learn what was important to us.
Q: How has Agile changed over the years?
So, to continue the story…
Fairly soon after the manifesto was published, it became apparent that it had touched a nerve. It became the subject of endless debate, teams started adopting XP and Scrum, and researchers starting looking seriously at whether it actually worked.
But, success always attracts the folks who want to capitalize on it. They want to offer training, or certification, or consultancy, or sell books. People started tacking the word Agile onto whatever they sold in the same way food producers would add “All Natural” onto their product packaging.
This may be a cynical view, but the word Agile became little more than a marketing term. It was abused so much that it lost its original meaning, and so has become worthless.
However, all is not lost…
Q: How do we reclaim Agile, or rather, Agility as a term from the consultants and the hacks? Is that even possible?
“Agile” is an adjective. You can say “an agile gymnast” or “an agile programmer.” It is not a noun. But the people who want to sell you things need a thing to sell—they need a noun. So, over the years, they have turned “Agile” into just that—a noun.
That has become my way of telling good from bad. If a company or consultant uses “agile” as a noun, then they are selling you something, and it is likely to be bullshit.
Let’s think about why.
A noun is a thing. If I buy myself some “Agile,” I’m buying something fixed and unchanging. It is people telling me “this is how you do Agile.”
But that can never be right. Every situation is different. Every team, every project, every customer—they are all unique, and anything that had agility would emerge from those combination of factors as something unique and evolving. By definition, agility is never static.
So what can developers do?
First, remember the underlying steps that describe agility:
- Know where you are now.
- Take a small step towards where you think you want to be.
- Review where you are now.
- Repeat.
On top of that, there’s just one practice:
Given a number of alternatives, choose the one that makes future change easier
This sounds simple, but it is really, really hard. It has to be applied at all levels, from how you name variables to how you build architectures. It recognizes that you never actually arrive, and that the trick is to make the journey enjoyable and productive.
Initially these can be individual developer practices. As people become proficient, they can see if they can extend the concepts to groups, so that teams can work with agility. And maybe, just maybe, they’ll remember to apply the steps to their methodology itself. It you’re still doing things the way you did them six months ago, you’re doing them wrong.
Q: What are you working on these days?
Mostly I’m thinking about the future of programming. I think most people agree that the future is functional and concurrent. That’s why I’m so excited about Elixir.
But a language alone does not solve the problems. Neither does a framework. What we need to be doing is coming up with different ways of thinking about programming which both exploit the language and framework features but that also enhance the way we perceive and model the world.
So I’m playing around in this space. I’m looking at day-to-day challenges (such as those of maintaining and updating pragprog.com) and asking myself how I could do this better in a functional way.
Perhaps surprisingly, what has me most excited at the moment is the way that classic finite-state machines seem to fit so tidily into functional pattern matching. I’m a long way off firming up my ideas, but so far I’m having a bunch of fun exploring them.
Q: What for you, is the single, most appealing part of Ruby?
If a sentence is ambiguous, then it is up to the reader to try to make sense of it. This means that an ambiguous sentence will engage you, will force you to stop and think, more than an unambiguous one.
Ruby is full of ambiguities, both syntactically and semantically. And I love this, because it keeps it fresh and keeps me thinking.
Q: What approach do you take to learning programming languages?
I have a series of small exercises I do—I call them kata. They start simple: a basic “Hello, World” program shows me I have the environment set up. From there I write a binary chop, maybe a sort, maybe roman numerals, and so on. If I’m really invested in a language, I’ll write a Markdown parser in it (because Markdown is full of special cases, and learning how not to make your code as ugly as the Markdown syntax is a great way to get to know a language).
But the only way to learn a language for real is to use it, day in and day out, until it becomes second nature; you must internalize it.
When you first start programming, this is daunting. Each new language could take 9 months or more to learn. But, after a while, your brain starts to draw parallels and find the abstractions, and a new language becomes less and less effort.
Until, of course, you bump into something truly new. Which is why I strongly recommend that all developers need to learn languages outside their comfort zones. If you already know C#, learning Swift is going to teach you a lot less than learning Haskell.
It was really great talking to Dave. He continues to be a mentor and positive presence in the programming community. I learned a lot, and I hope you did too.
Nihal SahuA Student/Web Developer/Writer with too much time on his hands. Life Goal: Become Aaron Patterson (@tenderlove)
