그렇지만 개발현장에서 유닛테스트 코드를 습관적으로 작성하는 프로그래머를 만나는 일은 쉽지 않다. 대부분의 프로그래머는 유닛테스트를 작성하는 데 거의 시간을 들이지 않는다. 그들은 요구사항의 윤곽이 대충 드러나면 곧바로 코딩을 시작한다. 코딩을 하다가 길이 막혀서 길이 보이지 않으면 처음으로 돌아가서 설계 자체를 검토하거나 리팩토링을 통해서 근본적인 문제를 해결하려고 노력하지 않는다. 대신 불리언 타입의 글로벌 변수를 선언한 다음, 꽈배기처럼 비비 꼬인 if-else 문장을 표창처럼 흩뿌린다. 그렇게 임시변통을 하고 길을 걷다가 길이 막히면 더 많은 불리언 변수와 더 많은 if-else 표창을 뿌리며 길을 헤쳐나간다. 그러다가 마침내 코드가 동작하는 방식이 요구사항이 설명하는 것과 대충 비슷한 것으로 보이면 손을 털고 일어선다. 프로그래밍이 끝난 것이다. 이렇게 작성된 코드는 당연히 수많은 논리적 오류와 버그를 내포하고 있을 수 밖에 없다. 하지만 걱정 없다. 버그가 보고되면 더 많은 if-else의 표창으로 버그를 잡아 버리면 되기 때문이다. 그리하여 코드는 버그가 하나씩 보고될 때마다 더욱 복잡해지고 난해해진다. 그러다가 마침내 프로그램은 코드를 작성한 프로그래머 자신조차 이해할 수 없는 누더기가 되어 버린다.
