'Essay'에 해당되는 글 86건

  1. 2010.08.14 [Essay] SW Debugging Skill vs. SW Programming Skill
  2. 2010.07.20 [Essay] SW Engineer의 Value…
  3. 2010.06.21 [Essay] Nokia's way?!
  4. 2010.04.05 [Prog] Object Oriented Programming
  5. 2010.02.26 [Essay][Review] Epilogue of the first SW project led by me.
  6. 2009.12.18 [Prog] Software design fundamental (my opinion)
  7. 2009.12.11 [Essay] 일을 맡기는 방법....
  8. 2009.09.04 [Prog] Do not underestimate costs for refactoring.
  9. 2009.08.10 [Prog] Step of progress (programming skill).
  10. 2009.06.04 [Prog][Debug] irregular bug....

[Essay] SW Debugging Skill vs. SW Programming Skill

Essay/Software 2010.08.14 22:03

예전에는 위의 두가지 Skill이 상당부분 유사하다고 생각했었다. 그런데 시간이 지나면서 위의 두가지 Skill에 작지않은 Gab이 존재함을 느낀다.
Debugging Skill(이후 D/S)과 Programming Skill(이후 P/S)간에 얼마만큼의 차이가 존재하는가?

한가지 예를 들어보자. 새로운 언어 (영어)를 배울때, reading skill과 writing skill간의 gap은 분명히 존재한다. 물론 극한에 이르려면 둘다 잘 해야 하는것은 명백하지만(만류귀종(?) 이라고 했던가..^^;), 어느정도 수준에 이르기까지는 서로 다른 방향에서 발전해 오다가 어느순간 교점을 가지는 듯 보인다. 과거 우리나라 학생들을 예로 들어보아도, reading skill은 뛰어나지만 writing skill은 부족한 경우가 많았다. 물론 그 반대도 존재한다. 대부분의 국내 대학생들의 reading skill은 미국의 저학년 초등학생의 그것보다 뛰어나다고 생각되지만, writing skill은 그렇지 못할 것이다. (어디까지는 필자의 생각이다.)

프로그래밍 언어도 마찬가지라고 생각한다. debugging을 위해서는 code reading skill(이후 R/S)이 중요하다. 그리고 Programming에는 code writing skill(이후 W/S)이 중요하다. 영어에서의 R/S, W/S간의 차이가 프로그래밍 언어에는 없으란 법이 있을까?
한 가지 예를 들어보면, P/S에서 가장 중요한 부분중에 하나인, design(class design, component design 등등) skill은 D/S에서는 별로 중요하지 않다. 반면, P/S의 경우, 내가 Programming할 분야 특화된 좁고 깊은 지식이 요구되지만,  D/S의 경우는 다양한 분야에 대한 넓고, (P/S에서의 경우대비 상대적으로)덜 깊은 지식이 필요한 경우가 많다.

각설하고, 요점은 이렇다.
두 Skill간에 차이는 분명히 존재하고, 이를 인정/감안 할 필요가 있다!
(물론, 만류귀종이라고... 어느 하나가 부족하다면, 다른 하나도 극한에 이를 수는 없다고 생각하지만....)

신고
Trackback 0 : Comment 0

[Essay] SW Engineer의 Value…

Essay/Software 2010.07.20 17:51

최근 나는, KLDP에서 data structure와 algorithm(이후 D/A)에 큰 관심이 없는 SW Engineer(이후 SWE)가 구글 코리아에 지원했다가 떨어진 내용에 대한 글 + 거기에 대한 글타래를 읽었다. (http://kldp.org/node/78668)
글타래를 보다보면, D/A에 익숙치 않은 SWE의 가치를 비하한다고 생각되어지는 몇몇 글이 눈에 띄인다. 난 이 post를 통해서 거기에 대한 반론을 전개하고자 한다.

모든 직종이 마찬가지겠지만, SW역시 다양한 분야가 존재한다. 그리고 Engineering skill의 가치는 "현재 종사하고 있는 분야에 얼마나 적합한가?"에 따라 측정되게 마련이다. 예를 들면, SW Integration Engineer의 경우, 각종 System 및 개발 환경, script와 tool의 사용 등에는 굉장히 뛰어난 skill을 보유하고 있을지 모르나, D/A에 대한 지식은 상당히 부족할 가능성이 높다. 그러나 그렇다고 해서, 뛰어난 SW Integration Engineer의 가치가 약해지거나 하는 것은 아니다. 그 사람은 본인의 직무에 적합한 skill을 가지고 있으므로, 우리는 그 사람을 충분히 '뛰어나다'고 이야기 할 수 있다. 나는 D/A가 중요하지 않다는 이야기를 하는 것이 아니다. 다만, 모든 SW분아가 D/A에 대한 skill을 요구하지는 않는다고 말하고 싶다.

SWE의 가치를 이야기할 때도 반드시 이러한 요소가 반영되어야 한다. 관련 글타래 중, "Google에서 정한 SWE의 가치(급여)가 현재의 급여보다 작다면, 현재 자신의 가치 이상의 급여를 받고 있을지도 모른다"는 의미의 글이 보인다 - 물론 내가 잘못 이해했을수도 있겠으나, 최소한 나에게는 이런 의미로 다가왔다. 그러나, 이는 분명히 잘못된 논리이다. 물론 현재 그 사람이 과한 급여를 받고 있을지도 모른다. 그렇지만, 최소한 그 기준이 Google의 급여가 되어서는 안되는 것이다. 왜냐하면, 현재 그 사람이 종사하는 분야가 요구하는 skill과 Google이 요구하는 skill이 엄연히 다르고, 각 회사는 자신들의 분야에 초점을 맞추어 SWE의 가치를 측정하기 때문이다. 다시 말하면, 그 사람이 현재 받는 급여는 현재 회사가 요구하는 skill을 기준으로 했을 때의 가치이고, Google이 제시한 급여는 Google이 필요로하는 skill을 기준으로 했을때의 가치가 되는 것이다.

"어떤 사람이 모든 측면에서 더 낫다."란  있을 수 없다. 이는 Engineering의 세계에서도 마찬가지라고 생각한다. 어느 한 분야에 국한했을때, "A가 B보다 낫다."라고 이랴기 할 수 있는 것이지, "A의 SW Engineering skill이 B의 것보다 낫다."라고 이야기 하기는 대단히 어렵다. 따라서, SWE의 일반적인 가치에 대한 측정은 대단히 신중해야 한다.

신고
tags : essay
Trackback 0 : Comment 0

[Essay] Nokia's way?!

Essay/Work 2010.06.21 20:03

듣기로.. Nokia는.. 어떤 문제에 대해서... 해결 방법을.. 찾을 때...

* 사람들을 모아서 해결책을 찾는 방법론을 listing한다. - brain storming
* 투표를 통해서 상위 2~3개를 뽑아낸다.
* 같은 의견을 가진 사람들끼리 모여서 팀을 형성한다. (2~3개 팀이 생긴다.)
* 각 팀별로.. 해결책을 찾는다....

--> 이 방법.. 상당히 괜찮아 보인다. 사람들은 자신과 신념/비젼을 달리하는 방향에 대해서는 최선을 다하기 힘들다. (무의식적으로 나태해지게 된다.)
그런데 이 방법은 자신이 믿는 바가 옳음을 보이는 형식이므로, 사람들의 적극적인 참여를 기대할 수 있다.

일반적으로, 사람은 의사결정에 본인이 참여한 정도만큼의 열정/책임의식 을 가진다고 한다. 따라서, 사람들의 열정을 이끌어내기 위한 중요한 방법 중 하나가, 의사 결정에 충분히 참여하도록 하는 것이다!

신고
Trackback 0 : Comment 0

[Prog] Object Oriented Programming

Essay/Software 2010.04.05 17:40

The most important thing of OOP is "Making objects that developer don't need to look inside of it.". Reliable objects are foundation of OOP. Then let's think about this more.

* Object should respond at all cases.

That is, crashing inside object should not be happened! object should be in valid state at any case. If software is crashed inside object, developer should analyze internal code of object, and this is what we want to avoid.

* Reducing possibility of misuse interface should be considered when interface is design.

That is, usage of interfaces should be easy and intuitive. If not, developer need to investigate for object's internal parts to know correct usage. And, usually, interdependent interfaces leads to misuse. For example, "Interface B should be used after interface A is called", "Interface A should not be called after interface B is called" and so on. So, if possible, reduce dependency among interfaces of objects.

* Interface should be well-commented.

In the same context with above, developer don't need to look into the object that is well-commented. In my opinion, comments of interface should include at least following things.
  + behavior of interface.
  + prerequisite to use the interface.
  + explanation about each parameters.
  + description about return value.
And, adding usage example is recommended.

* For object to starts supporting minimal set of interface is better.

Adding interface is easy. But deleting interface is difficult because it may affect to number of other objects that already use the interface. And, stabilizing object having small number of interface, is easier. Starting from minimal set can also help developer escape from temptation of over-engineering

 
Next important point is relations among objects.
Software created by OOP consists of lots of objects and relations. To understand software's behavior, knowing relations and inter-operations among objects is significant.

* Software documentation.

Design concept, policy, block diagram, used patterns and so on is needed to be documented to help reader to understand overall shape of software.

 
There is also disadvantage of OOP.

* Performance drop.

In every object, there are lots of routines for checking and handling unexpected cases. And in general, software in OOP consists of lots of objects. So, inevitably, number of duplicated check and handling are unavoidable - all objects may check same thing. And sometimes this drops performance very much.

신고
tags : OOP
Trackback 0 : Comment 0

[Essay][Review] Epilogue of the first SW project led by me.

Essay/Software 2010.02.26 22:05

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

+++ 내가 Lead했던 첫번째 SW Project가 끝났다... 이 경험을 보존하기 위해 Review를 적어본다. +++

Project인원 : 나를 포함해서 3명
프로젝트 기간 : 약 4개월..
규모 : 한 10,000 라인 정도 되나??

내 관점에서 보기에, 다른 두명의 Programming능력 수준은 기대 이하였다.(아니면, 나 자신이 그들의 능력을 보지 못할 정도로 미숙했을 수도...)
Programming 경험이 많지 않은 사람과 같이 일하면서 크게 문제가 되었던 점들은 아래와 같았다.

+ 기본적으로... Code의 Stability가 떨어진다. (많은 Bug를 내포하고 있다. 일정이 짧아서 그럴수도 있지만, 일단 돌아가는 코드만 만들고 Program의 구조는 신경쓰지 않는다.)

+ SW design의 중요성을 전혀 인식하지 못한다. (이게 가장 큰 문제다!!!) SW design의 중요성을 모르고, 상호간 Interface간 정의의 중요성을 모르기 때문에, 여기에 큰 관심을 기울이지 않는다. 아무리 이게 중요하다고 이야기해도 전혀 반응하지 않는다.(소 귀에 경읽기??) 이번 프로젝트의 경우, Interface에 대한 communication을 초반에 상당히 강조했음에도, 결국 Integration단계에서, 그들이 전혀 Interface의 중요성을 인지하지 못했고 또, 관심조차 기울이지 않았음을 알게 되었다. 그들은 자신의 module과 연결될 다른 모듈의 동작 방식으로, 모듈 작성자와 communication하지 않고, 자기 나름대로 상상해서 API를 정했다. 결국 Integration단계에서, 문제가 발생했다..

+ Code re-factoring을 하지 않는다.... 내 개인적인 생각으로는, 그들은 자신이 짠 코드를 버릴 줄 모른다. 첫번째 짠 코드보다는 두번째 짠 코드의 질이 좋을 수 밖에 없다. 그리고 필요한 경우, 첫번째 짠 코드의 전체를 버릴 수도 있어야 한다. 그런데, 어설픈 구조로 짠 코드를 벗어나지 못해, bug를 양산할 가능성이 있는 불안한 코드에 땜질하는 형태로 project를 진행시키고 있고, 그게 Project를 빨리 그리고, 완성도 높게 끝낼수 있는 길이라고 생각한다. 이는 결국, SW design을 모르는 것과 어찌보면 그 맥을 가치하는데 - 보통 re-factoring은 design이 좋지 않은 경우 수행되어 진다. - 자신의 코드의 design이 좋지 않다는 사실을 인지하지 못하므로, re-factoring을 해야한다는 사실 자체를 모른다.

그럼 이런 경우 어떻게 이를 극복해야 하는가?
궁극적으로는 같이 일하는 사람의 능력을 향상시키는 것이 가장 중요하겠지만, 당장 일을하기 위해서는 결국 SW design과 Interface, API등을 모두 정의한 상태에서 상당한 수준까지 design을 구체화 한다음, 나머지 부분을 채워 넣으라는 방식으로 일을 할당했다.
(결국 이렇게라도 일을 시켜야, 생산성을 이끌어 낼 수 있었다.)

반성
+ 사람마다 능력과 경험이 다르고 일하는 방식이 다르다. "내가 아는 것은 다른 사람도 알 것이다."라는 전제 자체가 잘못 되었으므로, co-work에 어려움이 있었다. 사람들간의 차이를 알고, 상황에 맞게 생산성을 이끌어낼 수 있는 방법을 찾는 노력을 기울이지 않았다.

신고
tags : essay
Trackback 0 : Comment 0

[Prog] Software design fundamental (my opinion)

Essay/Software 2009.12.18 00:35
[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

I want to say only one sentence about software design.

"Software design starts from and ends with [ separating things that will be changed with high possibility, from others that will not. ]".

In macro point of view, software requirement is main subject to classify. In micro point of view, function parameter, algorithm, data structure and so one can be targets.

신고
tags : Programming
Trackback 0 : Comment 0

[Essay] 일을 맡기는 방법....

Essay/Work 2009.12.11 19:55

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

======= 같은 실무자로서 일을 맡기기 (ex Lead Programmer) ========
일을 맡기기전에, "What"을 원하는지, 아니면, "What + How"를 원하는지 먼저 물어보고, 일을 시킬 필요가 있는 것 같다. 사람에 따라, "What"을 주고 일을 시킬 경우, 너무 막막해 하는 사람이 있고, "What + How"를 주고 일을 시킬 경우, 단순 노동을 시킨다고 짜증내는 사람이 있다.

따라서 일을 시키기 전에 미리, 이를 물어보고 선택의 여지를 주는 것이 좋아 보인다. 일에 자신이 있고, 자기 나름대로 무언가를 해 보고 싶은 사람 (사실 이런 사람을 원한다.) 에게는 "What"을 주고, 그렇지 않고, 아직까지는 일에 자신이 없고, 구체적인 일의 모습을 원하는 사람에게는 "What + How"를 주는 것이 좋다. 그러나 만약, 계속해서 "What + How"를 아주 상세한 level까지 줘야 하는 사람이라면, 같이 일하지 않는 편이 더 나아 보인다. 이런 사람은 관리하는데, 더 많은 시간이 소모되고, 또 더 많은 스트레스를 받게 된다.

또 한 가지 중요한 점은, 'What'을 주고 일을 시킨다고 할 지라도, 그 'What'의 내용이 너무 포괄적이거나, 추상적이여서는 안된다. 예를 들면, "좋은 코드를 만들어라". 같은건 말이 안된다. "Performance에 초점을 맞추어서 개발해라" 라는 식의 구체적인 모습을 주어야 한다. 이것이 중요한 이유는 일을 진행하는 중에, 서로 다른 가치가 충돌할 때, 어디에 더 비중을 두어야 할 지를 결정하는 기준이 바로, 일의 목적인 'What'의 내용이 되기 때문이다.

더불어 일의 진행상황이나 결과물을 reporting받아야하는데, 이때, deadline과는 조금 여유를 두고 받는 편이 좋다. 왜냐하면, reporting된 결과물이 원하는 형태가 아닐 확률이 높기 때문이다. 따라서, 2~3번 정도의 수정/검토를 염두해 두고 reporting 일정을 계획하는것이 좋다.

========= 실무를 모르는 관리자의 입장에서 일을 맡기기 ==========
실무에서 막 관리자로 역할이 바뀐 사람을 제외하고, 대부분의 경우, 관리자는 실무자에 비해 실무의 내용을 모른다. 또 몰라야 한다. (관리자가 이를 알려고 시간을 낭비하게 되면, 그 만큼 관리자가 해야할 일을 못하게 되기 때문이다.)

그럼, 실무를 모르는 관리자가 실무를 자신보다 더 잘 아는 실무자에게 어떤 식으로 일을 시켜야 하는가?

먼저 관리자는 자신이 실무자에 비해, 실무에 대한 구체적인 지식이 부족함을 인정해야 한다. (종종, 좋지 않은 관리자는, 자신이 실무자보다 실무경험이 더 많다는 점을 내세워 실무에 대한 구체적인 지식이 모자람에도 불구하고 이를 인정하지 않고 잘못된 방법론을 강요하는 경우가 많다.) 이를 전제로 관리자는 실무자에게, 구체적인 실무의 "How"에 대한 부분은 전적으로 맡기는 것이 좋다. 그럼 관리자가 할 일은? 관리자는 실무자에게 일의 방향성과, 요구되는 schedule등을 지시해야 한다. 즉 관리자는 "어떤 일을 언제까지 끝내야 한다."를 지시하는 것이지 "어떻게"를 지시하지는 못한다.(해서는 안된다.)

이때, 많은 경우 "언제까지"를 충족시키기 힘든데, 관리자는 이를 위해 실무자와 논의해서 최상의 결과를 얻을 수 있는 절충안을 찾아야 한다. 필요한 resource, requirement의 수정 등등.

다시 한 번 생각해 보면, 위의 과정은 관리자가 실무자를 신뢰함을 전제로 하고 있음을 알 수 있다. 즉 관리자는 실무자가 자신의 편의를 위해서 관리자를 속이지 않음을 전제한다는 말이다. 그런데 이는 너무 이상적인 가정이다. 많은 실무자가 자신의 편의를 위해, 일의 양을 부풀리거나 더 많은 resource를 요구할 것이다. 그렇다면 관리자는 어떻게 이를 방지할 것인가?

가장 좋은 방법은, 속이지 않는 실무자를 고용하는 것이다. ("인사는 만사") 자신에게 모든 인사권이 있다면 이런 사람을 뽑는데, 대부분의 시간을 할애해야 한다. 그렇게만 된다면, 이 문제는 더 이상 고민할 필요가 없다.

차선은, 실무자의 '도덕적 헤이'를 막기 위해, 해당 실무를 잘 아는 여러명의 실무자에게 같은 질문을 함으로서, 특정 실무자의 진심을 파악하도록 노력하고 이에 맞는 조치를 취해야 한다..

각설하고, 중요한 것은, 관리자가 실무자에게 "How"를 지시해서는 안된다는 뜻이다.!!!
손자병법에서도 전쟁에서 패하는 요인중에 하나를 "군주가 진격하지 말아야 할 때 진격을 명하거나, 후퇴하지 말아야 할 때 후퇴를 명하는 것"으로 뽑았다. 비단 전쟁 뿐이겠는가???

신고
tags : essay
Trackback 0 : Comment 0

[Prog] Do not underestimate costs for refactoring.

Essay/Software 2009.09.04 00:33
[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

Refactoring itself requires lots of costs. Especially, verifying result - refactored software - is extremely expensive. So, to minimize this costs, auto-test-system is essential. Don't underestimate the costs. Usually, making auto-test-system can save costs more than expecting.
신고
tags : Programming
Trackback 0 : Comment 0

[Prog] Step of progress (programming skill).

Essay/Software 2009.08.10 00:29

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

This id 100% personal opinion...
Step of progress in terms of programming skill(excluding co-working skill).

1. Coding with giving attention to the language syntax.
2. Coding his/her own thought quickly. (number of code line per hour is a lot. But, very buggy & poor design)
3. Realizing difficulty of debugging. So, coding considering debugging. initial speed becomes slower than (2)
4. Realizing software design. Coding considering design too. (slower than (3))
5. Knowing design techniques and importance of interface design, but immature. So, software is tended to be over-engineered. Lots of time is spent on designing over-engineered-software, interface and so on. In this stage, programmer knows about "What should be considered for good software". But he/she doesn't have any idea/experience about solutions. That's why initial speed is very slow.
6. Being mature. Becoming faster step by step.

신고
tags : Programming
Trackback 0 : Comment 0

[Prog][Debug] irregular bug....

Essay/Software 2009.06.04 00:14
[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Classifying non-regular bugs. (My opinion)

I usually classify non-regular bugs into 3 category.

(*1) : caused by timing. In multi-threaded software, sometimes unexpected execution order - ex. race condition - may raise error.
(*2) : caused by memory corruption. Memory is corrupted by some reasons - this is root cause, and because of this, error is occurred irregularly.
(*3) : caused by using uninitialized data.

Knowing that which category the bug belongs to, is very difficult and usually, only based on developer's experience.
Here one tip comes from my experience.

In case (*2) :
  reproducing way itself seems to be very irregular and the representation(result) of crash is also very un-determined.
In case (*3) :
  even if reproducing sequence is irregular too, the representation(result) tends to be simlar among cases. Usually, software is crashed from 'wrong memory reference'. And the overall outlook of crash is very regular.

신고
tags : Debug, Programming
Trackback 0 : Comment 0

티스토리 툴바