Software Engineering2006.03.06 02:44

소프트웨어 공학의 장기 베스트 셀러인 "Mythical Man-Month" 의 일부분이다. 20년전 책인데, 왜 아직도 이런 지적이 유효한 것일까....-_-;;;;;

Good Cooking takes time. If you are made to wait, it is to serve you better, and to please you.


훌륭한 요리는 시간이 걸립니다. 만약 당신이 기다리고 있다면, 그건 당신을 더 잘 모시기 위해서, 당신을 기쁘게 하기 위해서입니다.

-뉴올리언즈 안트완 식당의 메뉴

Most Software projects have gone awry for lack of calendar time than for all other causes combined. Why is the cause of disaster so common?

대부분의 소프트웨어 프로젝트는 모든 다른 이유보다도 일정의 부족으로 인해서 실패한다. 왜 이런 비극이 자주 일어나는 것일까?

First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.

첫째, 우리가 가지고 있는 일정 추정 기술이 아직 보잘것없기 때문이다. 더 진지하게 말하자면, 전혀 말도 안되는 가정, 이를테면 "다 잘되겠지" 등등에 기반하고 있고 있기 때문이다.

Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

두번째, 우리의 추정 기법은 불합리하게도 일정상의 진전(Progress)과 공수(Efforts)을 혼동하는데,  인원과 기간을 바꿔가면서 쓸 수 있다는(즉 기간이 모자라면 인원을 더 늘리면 된다는) 가정을 숨기고 있다.

Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef.

세번째, 추정에 확신이 없기 때문에 매니저들은 때로 안트완 식당의 예와 같은 완고함을 잃어버린다.

Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

네번째, 일정에 따른 경과가 제대로 모니터링되지 않는다. 다른 공학분야에서 검증되고 확립된 모니터링 기술들도 소프트웨어 공학에서는 아주 과격한 혁신으로 받아들여진다.

Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matter worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

다섯번째, 일정이 지연되었을 때, 대부분의 전통적인 반응은 인력의 추가이다. 그런데 이는 불에 가솔린을 끼얹는 것처럼 상황을 더 악화시킬 뿐이다. 더 큰 불이 더 많은 기름을 요구하는 것처럼 결국 실패로 끝나게 될 또 하나의 사이클을 시작시킬 뿐이다.

Posted by kkongchi