이론의 중요성
문제의 근원에 접근하면 할수록 이론의 중요성을 뼈저리게 느낀다. 학교에 다닐 때는 이론이 고리타분하고 현실에 쓸모없는 것이라고만 생각했다. 학교에서 더욱 현실에 가깝고 실질적인 지식을 가르쳐줬으면 하는 생각이 간절했다. 그러나 어느덧 3년차 회사원이 되어, 현장에서 문제에 부딪히면 부딪힐수록 결국 가장 특수한 경우의 문제도 이론과 결부되어 있다는 생각이 든다. 회사에서도 직원들을 교육시킬 때 이론의 비중을 높여야 할 것이다. 입사하자마자 바로 현업에 투입되는 건 어쩔 수 없는 중소기업의 현실이라 해도, 틈틈이 이론을 공부하고 지식을 공유하는 환경은 필수적이다. 특히 소프트웨어 개발자들의 경우 알고리즘, 데이터구조, 네트워크 및 데이터 통신 등 컴퓨터공학의 가장 핵심적인 과목들에 대해 숙지하고 있을 필요가 있다. 단기적으로는 교육의 손해가 있을 수 있지만 장기적으로, 또한 결정적인 순간에 이론은 결국 제값을 하기 마련이다.
얼마전 2007년 1월자 Communications of the ACM의 What Subjects and Skills are Important for Software Developers?라는 기사를 읽었다. 소프트웨어 개발자들 스스로가 가장 필요하다고 생각하는 스킬을 점수로 매겨 평균을 낸 것이다. 상위권의 결과는 다음과 같다.
Data Structure and Algorithms (3.8)
Procedural Programming (3.8)
Design (3.7)
Implementation (3.7)
Requirements (3.6)
Version and Configuration Management (3.6)
Object-Oriented Programming (3.6)
Test (3.5)
Software Architectures (3.5)
Internet Protocols (3.4)
....
Physics (1.6)
Artificial Intelligence and Knowledge Engineering (1.6)
이 결과는 어떤 점을 시사하는가?
Are Your Lights On?
How to Figure Out What the Problem REALLY Is
Donald C. Gause, Gerald M. Weinberg
Dorset House Publishing
<< I just blew up a few PARAGRAPHS by accidentally clicking the Google button on my Google toolbar!
Desperately hoped the content would remain while pressing Alt-Left, but to my despair everything was gone.
How come web applications do not restore the content or provide an auto-save? Well, maybe they do in some other applications.
<<
I have been trying to read this book since quite a while ago, but never was much into 'execution'. Finally I managed to order this book with several other books at Amazon. It was only the second English book that I read completely (the first one was 'the elements of style') among 50 other books that I have read this year.
This book is about problem solving. The authors are famous for their great insight in computer programming and problem solving. Rather than stating the 10 Commendments of problem solving, the authors took a long but more effective way. They tell a story in each section to end up with a sparkling insight. The book is very unique in the way of presenting the idea and insight - An illustration in every couple of pages, bold and capitalized texts all over to emphasize, a list of possible actions or solutions along with multiple choices, a brilliant sense of humor, etc. What they accomplished with such attempt is readers' attention and impact on their lessons to give. Let's have a look at some of these insights this book guides its readers to:
Part 1. What is the problem?
'A problem is a difference between things as desired and things as perceived.'
Part 2. What is the problem?
'You can never be sure you have a correct definition, even after the problem is solved.'
'But don't ever stop trying to get one.'
Defining a problem is sometimes harder than solving it.
Part 3. What is the problem really?
Each solution is the source of the next problem.
I totally agree, especially in the field of computer programming where it's all about side effects and ignoring/avoiding them.
The trickiest part of certain problems is just recognizing their existence.
If you can't think of at least three things that might be wrong with your understanding of the problem,
you don't understand the problem.
Once you have a problem statement in words, play with the words until the statement is in everyone's head.
This is very similar to lateral thinking.
Part 4. Whose problem is it?
If it's their problem, make it their problem.
This part brings up this story of the tunnel. Since there is a warning stating 'the tunnel ahead, lights on', all drivers turn their lights on. But what happens is they often forget to turn them off, later to find the dead battery. So what shall the designers do? 'Turn the lights off' wouldn't be wise because then the drivers would turn off at nights. (Common sense might lead them to leave the lights on, but anyway this doesn't sound like a perfect solution.) How about 'if daylight & lights on, turn it off. if night & lights on, leave it on. ...' Cars are surely going to crash with drivers reading this epic. The point of this situation is that the problem is not of the designer, but of the drivers. They don't need all that much details. What not just 'Are your lights on?' It's their problem. Let them solve by themselves.
Part 5. Where does it come from?
The problem actually comes from the problem solver 53.27% of the time.
(Don't tell me you want the source of their 53.27% research figure)
Who sent this problem? What's he trying to do to me?
Part 6. Do we really want to solve it?
Not all problems require solutions. There are time people don't even know what they want, and other times they just want the problem unsolved and eke out.
We never have enough time to consider whether we want it, but we always have enough time to regret it.
'The fish is always the last to see water.'
