개인적인 경험에의한 개발용어 사전정의로 몇가지 서적을 참고한
일반적이지 않는 정의입니다.
IT 용어
IT용어는 모든이가 동의하는 전문용어가 없음으로, 그것을 정의를 내리는 능력을 통해
상대의 수준을 가늠해서는 안된다. 진정한 프로는 그 단어를 인식하는 차이를 이해하려고
상대방에게 동의를 구하기위해 노력을 한다.
신기술
오래된 기술은 소프트웨어 위기를 가져오는 죄악으로 생각하며, 신기술 도입만이 해법으로
여기지만, 기술만으로 사실 큰 차이가 없으며 다음과 같음 끔찍한 결과를 낸다
- 소프트웨어 계약 가운데 50퍼센트는 비용을 초과함
- 60%는 스케쥴을 넘김
- 45%는 사용할수 없음
- 29%는 인도되지 않음
- 사용하려면 19% 재작업해야함
- 사용하려면 3%수정해야함
- 인도된 2%만이 사용할수 있으나, 문제가 해결된것은 없고 운영비용만 증가됨
은탄환
운영중인 소프트웨어가 괴물로 변할때, 은탄환을 장전해서 쏘면 그것이 해결되는것으로 보인다.
하지만 소프트웨어 공학읜 본질을 겨냥 하는 경우가 아닌, 우연히 발생하는 사건들을 겨냥하며
은탄환으로 얻는 생산성의 효과는 없다. 소프트웨어를 처음부터 만드는것이 아니라 어떻게 성장을
시킬것이냐가 중요하며. 때로는 그 은탄환은 소프트웨어가 아닌 사람을 겨냥하는것이 목적일때도 있다.
프로
- 아마추어는 리뷰를 귀찮게 여기지만, 프로는 환영
- 아마추어는 문서를 마지막에 작성하거나 안하거나하지만, 프로는 처음부터 작성
- 프로에게 개발주기는 잘 정의된 단계와 기준이 있다.
- 아마추어는 컴퓨터를 위한 프로그래밍을 하지만, 프로는 사람을 위해한다.
애자일
폭포수 모델의 한계를 언급하면서, 애자일 개발방법론을 이야기하는것이 보통이다.
하지만 이것을 이야기하는 사람은 폭포수 모델을 제대로 경험하지 못하거나, 그것을 개선하기위해
변형을 해본적이 없는 사람들이 대부분이다. 적어도 폭포수는 위에서 흘러서 아래로 내려가며
운영에대한 경험없는 전문가의 이론을 따라 프로세스를 개선하면 물조자 흐르지 않아 막히는 경우가 대부분이다.
물론 간접적으로 배우는것이 항상 틀리다란 말은 아니며 , 경험이 있다고 항상 올바른 방향을 제시하는것도 아니다.
문제는 경험없는 사람의 입담으로인해 구세주인것처럼 여기는 문화가 되어서는 안된다란 것이다.
해결책
고약한 문제를 푸는 해결책은 모두 일회성작업이다. 왜냐하면 시행착오를 통해 배울 기회가없으며
모든 시도가 실패하면 안되는 해결책이 되어야 하기 때문이다. 그리고 알고 있는 한가지 경험은 실제로 신규시스템은 실패를 하였고,
실패에 대한 인정없이 자연스럽게 되돌리려고 한다. 이 모든것은 가장 강력한 결정권자가 승인을 하였으며,
그것을 진행한 몇몇은 조용히 있을뿐이며 책임자는 찾아볼수가 없다.
그리고 다시 원복하는 과정에서 기존 레거시라고 괴물 취급 받았던 시스템이 새롭게 하려던것을 해내면서
플랫폼의 문제가 아님을 깨닫게 된다. 최근 모던한 플랫폼을 살펴보아도 대부분 상호 운영에 포커스가 맞추어져 있다.
밭을 갈아 엎어 생산성을 높이던 시대는 이미 끝났다.