avoid the jam

On the other hand, if you want to keep your options open and steer clear of such challenges, the obvious conclusion and take-home lesson is to avoid the problem in the first place. Sure, you can wait until you're stuck in a traffic jam before you consider alternative routes, but by that time it's too late to avoid the jam — all of your efforts are focused on trying to get out of it. You're better off keeping your eyes on the road and your ears on reports of the route ahead.

-----------------------------------------
About the author: Kevlin Henney is an independent consultant and trainer based in the UK. His work focuses on software architecture, patterns, development process and programming languages. He is a coauthor of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two recent volumes in the Pattern-Oriented Software Architecture series.

about a tapestry fire

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.

broken window theory

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."

Communication

The Tree of Knwledge (Maturana 1998)

Person ======== Person
(mensaje)

Each person hears what he hears according to his own structural determination...The phenomenon of communication does not depend on what is trasmitted, but on what happens to the person who receives it. And this is a very different matter from 'trasmitting information'.

Agile Software Development (2nd Edition) Alistair Cockburn

To put this into a concrete example, suppose someone runs into the room and shouts "Fire!" in Japanese. A Japanese-speaking listener receives a lot of information and immediatly leaps up and runs to the exit. The Japanese person next to him, who happens to be asleep, receives no information at all. The external stimulus was never converted into an internal signal. A person who speaks no Japanese notices that someone came in and shouted something, but he received no particular information form the sounds uttered. What each person receives from the shout depends on his internal condition.

New Knowledge

Quotes
From Alistair: "Computers must support the way in which people naturally and comfortably work. This is needed both for personal job satisfaction and for corporate survival. I care about whether the team is thriving, and whether the software is being delivered. Keeping the people trained and the process light are key to both."