Lazy Developer

Learn from all experiences

모든 경험으로부터 배운다.

"결정적인 국면에 처했을때 임무를 수행하는 능력은 당신이 그것을 할 수 있다는 자신감에서 나온다. 그 자신감은 어디서 나올까? 과거에 그것을 해보았기 때문이다. 물론, 일단은 처음 그것을 시도해 보아야 하겠지만 그 다음부터는 항상 되돌아 볼 수 있는 귀감이 생기는 것이다. 전에 해보았던 것을 할 때는 마음이 편안해진다.

자신감과 자부심이 관건이다. 자신감은 전에 해보았던 일이라는 생각에서 우러나온다. 연습도, 훈련도, 그 무엇도 하고 싶지 않았던 때가 있었지만 내가 다시 마음을 잡은 것은 누군가가 나를 따라잡는 것을 원치 않았기 때문이다. 바로 그런 이유로, 마지막 2분을 남겨놓고 경기가 초긴장의 상황으로 접어들 때는 내가 어떤 다른 선수들보다 유리하다고 느낀다."

마이클 조던이 ESPN에 기고한 글의 일부이다. 출처는 여기

다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)
Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)

품질에 투자한다.

Whitepaper에도 언급하고 있지만, 절대적으로 완벽한 품질이란 있을 수가 없다. 품질이란 계속해서 쌓아가는 것, 발전해 나가는 것이다. 그러므로, 품질은 프로젝트의 모든 과정에서 고려되어야 한다. 즉, 일단 돌아가게 만든 다음에, 품질을 높인다..라는 어프로치는 안 된다.

MSF에서는 퀄리티 추구를 위해서 두 가지 - 테스팅 팀을 중시하는 팀 모델, 개발자들의 Readiness 관리를 위한 교육 모델 - 를 제안한다. 말은 쉽지만 이 두가지가 모두 잘 되는 프로젝트는 현실적으로 찾기 힘들다. 여러 가지 이유 - 예산의 문제, 일정의 문제 등등 - 로 인해서 소홀해지기 쉬운 부분이기 때문이다. 하지만 결국 이런 부분을 소홀히 했을 때, 결과적으로 퀄리티는 당연히 떨어지기 마련이다.

Stay agile, expect change

언제나 유연하게 변화에 대응할수 있도록 한다.

"It is one of the constants of software development that the requirements change."
"요구사항의 변화는 소프트웨어 개발에서 상수(Constants)중의 하나이다"

다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)
Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)

Focus on delivering business value

비즈니스 가치에 초점을 맞춰야 한다.

사실 내가 그동안 해왔던 Enterprise SI에서는 이 부분이 부족하다고 말할 수 있다. 고객이 원하는 소프트웨어를 거기에서 만들어주는 일이 대부분이기 때문에, 당연히 일을 하는 만큼 어느 정도 돈은 나올테니까.

하지만, 솔루션을 만들어서 시장에 내놓는 일을 하는 업체, 혹은 최근에 많은 웹기반의 일반 사용자용 소프트웨어(웹 2.0이라고 해야 하나?)를 만드는 업체라면 이 부분은 아주 중요하다. 즉, 시장에서 팔릴 수 있는 것, 고객이 돈을 내고 살만한 것을 만들어야 할 것이다. 이런 비즈니스적인 결과가 따라오지 못한다면 개발자나 기획자 등의 동기부여도 잘 안 될 것이고, 틀림없이 결과도 좋지 못할 것이다.

Establish clear accountability and shared responsibility

팀(개인)의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다.

이 원칙을 지키지 못했을 경우에 가장 문제가 될 수 있는 것은 MSF White Paper에서도 지적하고 있듯이, 작업의 중복으로 인한 과잉 작업 혹은 작업의 실종(?)으로 인해서 발생되는 누락등이다. 이건 결과적으로 프로젝트에 매우 큰 해를 끼칠 수 있고, 프로젝트의 실패로 이어지기도 한다.

팀 혹은 개인의 의무를 분명히 하는 것은 사실 어렵지 않다. 처음에 세심하게 준비하고 문서화함으로써 각 팀 혹은 개인이 그 프로젝트에서 갖는 의무를 분명하게 만들 수 있다.

문제는 2번째이다. 전체적인 책임은 모든 팀/개인이 공유해야 한다는 것. 만약에 어떤 팀 혹은 개인이 자신의 의무를 다 하지 못하고. 실패를 한다면 그 것을 누군가는 메꿔야 한다. 그랬을때, 사실 팀 또는 개인이 자신의 일이 아니라는 이유로 방관할 수도 있고 혹은 자신의 일 이외 부분에 대한 이해가 부족해서 그런 작업을 잘 하지 못할 수도 있는 것이다. 즉 프로젝트에 속한 모든 팀/개인이 전체적인 그림에 대해서 이해하고 전체적인 책임을 공유할 수 있어야 이런 작업에 대해서 실패하지 않을 수 있다. 책임을 모두 공유해야 한다는 것은 바로 그런 의미이다.

• System.Collections.ObjectModel.Collection<T>
• System.Collections.ObjectModel.ReadOnlyCollection<T>
• System.Collections.ObjectModel.KeyedCollection<Tkey, TItem>

When running in Integrated mode in IIS 7.0, ASP.NET modules run in the unified request processing pipeline side-by-side with native C++ IIS modules. This means that existing ASP.NET services like Output Caching, URL Rewriting, and any others provided by your custom ASP.NET modules can now apply to any content type. Better runtime integration also enables ASP.NET modules to access previously unavailable server functionality, removing the need to write native IIS extensibility in most cases.
IIS 7.0이 통합 모드로 운영될 때, ASP.NET모듈은 Native C++ IIS모듈과 나란히 통합적인 리퀘스트 처리 파이프라인에서 동작하게 된다. Output 캐싱, URL 리라이팅과 같으 기존의 ASP.NET 서비스나 혹은 다른 당신이 만드는 별도의 서비스들이 이제는 모든 컨텐트 타입에 적용되게 된다. 개선된 런타임 통합은 ASP.NET이 이전에는 불가능했던 여러 가지 기능을 할 수 있도록 해주며, 결국 기존에 Native IIS 확장 모듈을 만들어야 했던 경우들은 이제 없게 될 것이다.