A Conversation with Andy Hunt and Dave Thomas, Part I

Andy Hunt and Dave Thomas are the Pragmatic Programmers, recognized internationally as experts in the development of high-quality software. Their best-selling book of software best practices, The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 1999), is filled with practical advice on a wide range of software development issues. They also authored Programming Ruby: A Pragmatic Programmer's Guide (Addison-Wesley, 2000), and helped to write the now famous Agile Manifesto.

In this interview, which is being published in ten weekly installments, Andy Hunt and Dave Thomas discuss many aspects of software development. In this first installment, they discuss the importance of software craftsmanship and the importance of staying on top of the small problems in your projects.

Craftsmanship and Cathedrals

Bill Venners: In the preface of your book, The Pragmatic Programmer, you quote a Quarry worker's creed:

We who cut mere stones must always be envisioning cathedrals.

You then say "Within the overall structure of a project there is always room for individuality and craftsmanship." What do you mean by that?

Dave Thomas: In a very structured environment, people tend to abdicate responsibility. People say, "It's not my job anymore. My boss is telling me what to do. A big master plan is given to me. I just have to do this module, and this module, and this module." The analogy is with a stone mason who is a very small part of a very big whole. The reality is that the stone masons building the cathedrals were seriously high quality craftsmen. They were always conscious of the fact that the work they were doing was going to be the face of a cathedral. What we're saying is, even if you feel you don't have the authority or responsibility to do it right, the reality is you do. The quality of the work you are doing is important. It contributes to the overall impact or effect of the project.

Andy Hunt: The other facet is that this allows or encourages individual artistry. You can't go hog wild. You're building a cathedral. You have to carve your gargoyle to fit into the overall theme and coherent tone of the place. You can't start carving swans or something. But within the overall design constraints of the whole, you still have that individual artistic liberty to do your best work as it relates to that whole.

Bill Venners: Why is that important?

Dave Thomas: Two reasons. First, programming is very difficult. To do it well requires a phenomenal amount of commitment. To motivate yourself and keep yourself committed, you need to have pride in what you're doing. If instead you consider yourself a mechanical assembly line worker, whose only job is to take the spec and churn out bytes, then you're not going to have enough interest in what you're doing to do it well. So from the global perspective, it is very important. From a personal perspective, why should you be doing work you don't enjoy? It is important if you are going to commit this much to a job that you enjoy it.

Andy Hunt: The idea of artistic freedom is important because it promotes quality. As an example, suppose you're carving a gargoyle up in the corner of this building. The original spec either says nothing or says you're making a straight on gargoyle just like these others. But you notice something because you're right there on the ground. You realize, "Oh look, if I curve the gargoyle's mouth this way, the rain would come down here and go there. That would be better." You're better able to react locally to conditions the designers probably didn't know about, didn't forsee, had no knowledge of. If you're in charge of that gargoyle, you can do something about that, and make a better overall end product.

The Broken Window Theory

Bill Venners: What is the broken window theory?

Andy Hunt: Researchers studying urban decay wanted to find out why some neighborhoods escape the ravages of the inner city, and others right next door—with the same demographics and economic makeup—would become a hell hole where the cops were scared to go in. They wanted to figure out what made the difference.

The researchers did a test. They took a nice car, like a Jaguar, and parked it in the South Bronx in New York. They retreated back to a duck blind, and watched to see what would happen. They left the car parked there for something like four days, and nothing happened. It wasn't touched. So they went up and broke a little window on the side, and went back to the blind. In something like four hours, the car was turned upside down, torched, and stripped—the whole works.

They did more studies and developed a "Broken Window Theory." A window gets broken at an apartment building, but no one fixes it. It's left broken. Then something else gets broken. Maybe it's an accident, maybe not, but it isn't fixed either. Graffiti starts to appear. More and more damage accumulates. Very quickly you get an exponential ramp. The whole building decays. Tenants move out. Crime moves in. And you've lost the game. It's all over.

We use the broken window theory as a metaphor for managing technical debt on a project.

Bill Venners: What is technical debt?

Andy Hunt: That's a term from Ward's Wiki. (See Resources.) Every time you postpone a fix, you incur a debt. You may know something is broken, but you don't have time to fix it right now. Boom. That goes in the ledger. You're in debt. There's something you've got to fix. Like real debt, that may be fine if you manage it. If you've got a couple of those—even a lot of those—if you're on top of it, that's fine. You do a release get it out on time. Then you go back and patch a few things up. But just like real debt, it doesn't take much to get to the point where you can never pay it back, where you have so many problems you can never go back and address them.

Dave Thomas: My current metaphor for that is my email inbox. Because I have this habit every now and then of not answering email for a while. And then it gets to the point round about the 250 message mark, where I suddenly realize, I'm never going to answer these messages. And it is the same with pending changes in software.

Bill Venners: How does technical debt relate to the broken window theory?

Andy Hunt: You don't want to let technical debt get out of hand. You want to stop the small problems before they grow into big problems. Mayor Guiliani used this approach very successfully in New York City. By being very tough on minor quality of life infractions like jaywalking, graffiti, pan handling—crimes you wouldn't think mattered—he cut the major crime rates of murder, burglary, and robbery by about half over four or five years.

In the realm of psychology, this actually works. If you do something to keep on top of the small problems, they don't grow and become big problems. They don't inflict collateral damage. Bad code can cause a tremendous amount of collateral damage unrelated to its own function. It will start hurting other things in the system, if you're not on top of it. So you don't want to allow broken windows on your project.

As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can't fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn't trust it, shouldn't go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. "Well, that's broken. Oh I just broke that. Oh well."

Show You Care, So Others Will Care

Dave Thomas: It comes down to showing that you care. Take for example some code that is kind of shared among the team, but primarily is mine. There's some code in there that is obviously bad, but it doesn't look like I care about it. I'm just leaving it bad. Anybody else coming into that module might say, "Well, Dave doesn't care about it. It's his module. Why should I care about it?" In fact, if you come into my module and do something else that's bad, you can say, "Well, Dave doesn't care. Why should I care?" That kind of decay happens to modules as well as apartment buildings.

On the other hand, suppose I notice an edge condition that doesn't work in my code. I know it's a bug, but the bug is not critical to the application today and I don't have time to fix it. I could at least put a comment in there. Or, even better, I could put assertion in there, so that if the edge condition ever hits, something's going to happen that shows I'm on top of it. By doing that, first of all I make it easier to identify the problem. But I also show other people that I care about that enough that they will fix problems too when they encounter them.

Andy Hunt: If you walk into a project that's in shambles—with bugs all over, a build that doesn't quite work—you're not going to have incentive to do your best work. But, if you go onto a project where everything is pristine, do you want to be the first one to make a bug?

Bill Venners: In your book you tell a story about a tapestry fire.

Andy Hunt: That is a true story. A former accountant of mine in Connecticut lived in a very up-scale, wealthy section of town. This guy lived in a super mansion. He had a tapestry hanging on his wall a little too close to his fireplace, and one day it caught fire. The fire department rolled in. The fire was blazing. The house was about to go up in flames. But the fire department did not simply come charging in the front door. They opened the front door, and they rolled out a little carpet. Then they brought their filthy dirty hoses on their carpet and put the fire out. They rolled their carpet back up and said, thank you very much.

Even with the fire raging, the fire department took the care to put down the carpet and keep their hoses on it. They took extra special care not to mess up this guy's expensive mansion. It was a crisis, but they didn't panic. They maintained some level of cleanliness and orderliness while they took care of the problem. That's the kind of attitude you want to foster on a project, because crises do happen. Stuff bursts into flame and starts to burn up. You don't want to go running around crazy and causing more damage trying to fix it. Roll out the carpet. Do it right.

Next Week

Come back Monday, March 10 for Part II of this conversation with Pragmatic Programmers Andy Hunt and Dave Thomas. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Andy Hunt and Dave Thomas are authors of The Pragmatic Programmer, which can be purchased from Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020161622X/

The Pragmatic Programmer's home page is here:
http://www.pragmaticprogrammer.com/

The Agile Manifesto is here:
http://agilemanifesto.org/

Ward's Wiki, the first WikiWikiWeb, created by Ward Cunningham, is here:
http://c2.com/cgi/wiki?WelcomeVisitors

Talk back!

Have an opinion? Readers have already posted 9 comments about this article. Why not add yours?

About the author

Bill Venners is President of Artima Software, Inc. and Editor-In-Chief of Artima.com. He is the author of Inside the Java Virtual Machine (Computing McGraw-Hill), a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard for associating user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.