책과 엔지니어✍️: 해결책과 비용

📕 “개발자가 명세서만 단순히 읽으면 해당 소프트웨어를 사용하는 사람들에게서 고립된다. 사람들이 제품을 어떻게 사용할지 모르기 때문에 코드가 투박해지고 오류가 발생하기도 쉽다. 이뿐이 아니다. 개발자가 열정을 못 느끼고 어떻게 완성할 것인지 직관이 없기 때문에 코드를 작성하는 데 오랜 시간이 걸린다. 개발자와 함께 일해 봤거나 사내에 소프트웨어 개발팀이 있으면 알겠지만, 이게 바로 소프트웨어를 빨리 개발하지 못하는 어려움을 겪는 이유다. 개발은 언제나 사측이 원하는 것보다 오래 걸리는 것처럼 보인다. 채드 에츨(일명 재지 채드)은 이런 일이 매니저가 개발 초반에 문제를 정의할 때 개발자를 배제하고 어떤 솔루션을 구축해야 할지 지시만 하는 잘못된 프로세스에서 비롯한 자연스러운 결과로 본다.” - <개발자에게 물어보세요> 💬 내 경험상 개발에 시간이 오래 걸리는 이유는 문제의 뿌리를 모른 채 해결책이라고 주어진 일을 수행할 때이다. 콘크리트와 같이 구체적인 해결책을 구현하기 위해 열정 없이 어떻게든 코드로 만들어내는 데만 고민하는 데서 발생하는 비용. 열정 없이 작성된 투박한 코드 덕에 순간순간에 터져 나오는 에지 케이스를 대응하는 데서 발생하는 비용과 대응 중에 코드 베이스를 수정해야 하는 데서 발생하는 비용. 그 와중에 이 내가 개발하고 있는 이 기능이 정말 해결책이 맞을까에 대해 스스로 의심하는 순간. 구체적으로 주어진 해결책을 구현하는 데에 개발자에게 주어진 시간이 5일이었다. 하지만 구체화 되지 않은 문제점만 주어졌을 때 하루 안에 쉽게 해결할 수 있는 문제였다면 어떨까? 실제로 5일 이상이 걸릴 수 있는 문제의 해결책이 단순히 문제점만 공유됐을 때 쉽게 풀리는 경우가 많다.