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