TIL
범위
- 실용주의 철학 - 적당히 괜찮은 소프트웨어
기억하고 싶은 내용
실세계에서는 진정 완벽한 것을 만들어 내기란 불가능하다. … 특히 버그 없는 소프트웨어는 더더욱. 시간, 기술, 기질 같은 것이 모두 공모해서 우리를 방해한다. 42p
적당히 괜찮은 —사용자, 미래의 유지보수자 혹은 자기 마음의 평화를 유지하기에 적당히 괜찮은— 소프트웨어를 만들도록 자신을 단련할 수 있다. 42p
‘적당히 괜찮은’이라는 문구는 너절하거나 형편없는 코드를 의미하지 않는다 시스템이 성공하려면 사용자의 요구사항을 충족해야 한다. 43p
우리는 여러분이 생산해 낸 것이 어느 정도면 적당히 괜찮은지를 결정하는 과정에 사용자가 참가할 기회를 가져야 한다는 걸 말하고 있는 것이다. 43p
품질을 요구사항으로 만들어라. p44
오늘의 훌륭한 소프트웨어는 많은 경우, 내일의 완벽한 소프트웨어보다 낫다. 사용자들에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 솔루션에 도달할 수 있을 것이다. p44
예술가들은 여러분에게 언제 멈춰야 할지를 알지 못하면 이 모든 고된 작업을 망치게 될 거라고 말해 준다. p44
완벽하지 않을 수도 있다. 걱정하지 마라. 완벽해지기란 불가능하다. p44
소감
사용자로써 소프트웨어를 경험하면서 이번 챕터에 공감을 많이 했다. 물론 프로그래머들의 완벽성과 기술적으로 예술성(?)의 부분은 내 식으로 자본주의 디자이너로의 경험에 대입하여 공감했다. 사실 어느 직업군이든 사람에 따라 공감할 수 있는 부분이라고 생각한다. (미용사 언니도 내가 드라이를 대충해달라고 할 때마다 떨떠름하게 생각한단다.) 책에서 나온 것처럼 시간과 기술.. 그런 것들이 완벽한 소프트웨어를 만들려고 하는 우리를 방해하려고 공모한다! 완벽한 것을 만들 수 있다는 생각을 멈추고 사용자의 요구사항을 받아들이면 생각보다 ‘적당히 괜찮은’ 것이 나올 수 있다.
::TODO::
모듈화가 소프트웨어 납품에 미치는 영향을 고려해보라. 모듈로 설계된 시스템을 만드는 것과 비교해, 거대한 덩어리 하나로 된 소프트웨어를 요구된 품질 수준으로 만드는 게 더 오래 걸릴까, 적게 걸릴까.
