깨진 창문 이론

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.

연구를 더 계속한 끝에 "깨진 창문 이론"이라는 것이 나왔습니다. 아파트 건물에 창문이 깨졌을 때 아무도 고치지 않으면, 깨진채로 남아 있습니다. 그러면 또 다른 창문이 깨집니다. 실수로 그랬을 수도 있고 일부러 그랬을 수도 있지만, 그것도 고쳐지지 않습니다. 낙서가 등장하기 시작합니다. 점점 더 훼손됩니다. 기하급수적으로 진행되어 전체 건물이 쇠락합니다. 입주자들은 나가고 범죄자들이 들어옵니다. 그럼 게임은 끝난거죠.

...

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 import!ant 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."

뭐가 고장나자마자 - 코드이건, 방법론이건, 요구사항이건, 문서의 잘못이건 간에 - 무언가가 잘못되었다는 것을 안다면 즉시 멈추고 그 자리에서 그 문제를 처리해야 합니다. 고칠 수 없다면, 테이프로 주변을 봉하고 나무판을 덮고 못질을 해서 모든 사람에게 그것이 잘못되었다는 것을 알려야 합니다. 사람들로 하여금 그것을 믿지 말고 근처에도 가지 말도록 해야 합니다. 상황이 수습중에 있다는 것을 알리는 것은 실제로 고치는 것 만큼이나 중요합니다. 무언가가 잘못되었는데 고치지 않는다면 즉시 팀 전체에 문제가 확산됩니다. "저런, 저건 잘못되어 있네. 이런, 또 잘못했네. 다 그렇지 뭐."

- 퍼온글입니다. 실용주의 프로그래머에 나온 글이라네요.