Ting 이네 Software 이야기

[[ 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에 어려움이 있었다. 사람들간의 차이를 알고, 상황에 맞게 생산성을 이끌어낼 수 있는 방법을 찾는 노력을 기울이지 않았다.

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.

[[ 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"를 지시해서는 안된다는 뜻이다.!!!
손자병법에서도 전쟁에서 패하는 요인중에 하나를 "군주가 진격하지 말아야 할 때 진격을 명하거나, 후퇴하지 말아야 할 때 후퇴를 명하는 것"으로 뽑았다. 비단 전쟁 뿐이겠는가???

[[ 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.

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.

(삼가 고인의 명복을 빕니다.)

[사람들은 "전부 노무현 탓이다."라고 이야기 하면서, 모든 것을 그의 탓으로 돌리며 그를 비판했다.]

[그렇지만, 그는 그냥 묵묵히 말없이 바위처럼 있었다. ]

난 그가 민주당 경선 후보로 나왔을 때부터, 그러니까 '노사모'가 결성되었을 때 즈음부터 노무현을 지지했었다. 그리고, 그가 보수 언론과 야당의 비판에 휘둘려, 국민들의 지지를 잃어갈 때에도 난 그를 지지했었다. 그리고 그가 퇴임하는 순간, 최악의 지지도에 괴로워했을 때에도 그를 지지했었다. 그냥 하는 이야기가 아니라, 정말이다. 난 그를 끝까지 지지했었다.

그런 그가, 떠났다. (모르겠다. 경찰은 자살이라고 발표했다. 언론도 그렇게 이야기한다. 그렇지만 항상, 진실은 경찰발표와 언론 저 너머에 있었다. 자살인지, 아니면 타살인지 모르겠다. 그렇지만, 노무현 그가 이 세상을 떠났다는 것은 부정할 수 없는 사실이다.)

2009년 5월 23일 그의 서거 소식을 들었다.(사실 23일 당시 언론은 '서거'가 아니라 '사망'이라는 표현을 먼저 썼다. 그래서 난 처음에는 누군가 장난치는 줄 알았다.)

멍~ 했다. 그리고 분노했다. 사실이든 사실이 아니든, 난 정치보복성 수사가 그를 죽음으로 몰고 갔다고 믿는다.(모르겠다. 이런 글을 쓰면, 또 검찰에서 딴지를 걸고 넘어질려나... 지금의 검찰은 그러고도 남을 듯 하다.) 그리고, 현 정권(17기 이명박 정권)에 분노를 표출했다. 그런 분노가 계속되고, 금일 29일(금요일) 영결식날 난 회사에 휴가를 내고 경복궁을 향했다. 그리고 다시 한 번 분노했다. 추모객 숫자보다 더 많아 보이는 전경들, 경복궁 근처에는 얼씬도 하지 못하게 하는 저지선, 그리고, 어디 광고에나 쓰일법한 전광판에서 방송되고 있는 영결식을 보고 있으라는 말... (특히 "조선일보"라는 큰 건물 명 아래에 위치한 전광판에서 '영결식'이 방송되는 모습은 정말 말로 표현하기 어려운 황당함과 분노를 일으켰다.)

그리고 난 이러한 분노가 이성을 막아설까봐 두려워, 집으로 발길을 돌렸다. 시청앞광장 노제를 뒤로한체... (나의 성격을 잘 아는 집사람이 시청에 가는 것을 극도로 반대했었던 것도 이유 중 하나였다. 지금은 두 가지 심정이 복잡하게 얽혀있다. 과연 그때 뒤돌아 온것이 잘한 것인지 아닌지... 마지막 가시는 길을 배웅하지 못한 안타까움과, 분노에 이성을 잃을 수도 있었으나 잘 참아낸 선택이였다는, 두 가지 상반된 생각의 혼재가....)

그리고 집에서 생방송을 지켜보았다. (이명박 정권부터는 뉴스 및 기타 시사 프로는 되도록이면 MBC를 본다.) 말없이 하염없이 방송을 지켜 보고 있던 가운데, 29일 저녁쯤, 처음으로 내 눈에서 눈물이 흘렀다.

사람들은 '지켜주지 못해서 미안하다.' 라고 말했다.

그랬다. 눈물을 흘리면서도, 왜 내가 이렇게까지 슬퍼하고 있는지 나 자신도 몰랐는데, 이유는 그거였다.

앞서 이야기 한 것처럼, 난 노무현을 지지해 왔었다. 그렇지만, 반 노무현의 목소리가 높았을때, 난 "나도 노무현을 좋아하지는 않지만..." 으로 시작하는 말로, 소극적으로 그를 지지했었다.

그랬다. 난 비겁했다. 난 당당하지 못했다. 그렇지만, 그는 언제나 당당했다.

오 바마 현 미 대통령이, 그의 당선의 변에서, "내가 하는 일이 모두 옳은 일은 아닐지언정, 난 내가 하는 모든 일을 정직하게 하겠다."(정확하게 이 말이 맞는지는 모르겠으나, 뜻은 거의 비슷할 것이다.)라는 말이 생각났다. 그랬다. "바보 노무현"은 그랬다.

그는 결코 그의 신념을 굽히지 않았다. 타협하지 않았다. 그런 그를 지지하면서도, 난 비겁했다. 그 미안함. 그게 아마도 눈물이 되어 흘렀으리라.

그 가 그렇게 힘들고 고독하게 싸우고 있음에도, 난 비겁했고, 소극적이였다. "난 힘이 없어." "난 아무것도 변화시킬 수 없어."라는 자기 변명으로, 비겁하게 난, 도망쳤다. 그리고, 지금의 내가 가지고 있는 것들을 잃는게 두려워 비겁하게 도망쳤다.

그리고, 이제 그가 갔다.

그런 그가 나에게 묻는다. 넌, 타협하지 않고, 신념과 소신을 굽히지 않고, 당당하게 나아갈 수 있느냐고...

(난 그가 했던 모든 것들이 '옳다'고 이야기 하고 있는게 아니다. 그는 정직했고, 당당했고, 원칙과 소신에 따랐다. 그걸 이야기 하고 있는 것이다.)

그런 그에게 부끄럽지 않고 싶다.

난, 아직 한번도 정치적인 사안에 대해 인터넷에 글을 올려 본 적이 없다. 두려웠기 때문이다. 그렇지만, 지금 이 순간 처음으로 글을 올린다.  나의 비겁함에 대한 작은 속죄로, 또 부끄럽지 않는 삶의 작은 첫걸음으로...(이 글을 공개하는 것은 아무래도 조금더 긴 생각이 필요할 듯 하다. 괜시리 그에게 의도하지 않은 피해를 줄 수도 있기에...)

다시 한번 삼가 고인의 명복을 빕니다.

사랑했었고, 사랑하고 또 앞으로도 사랑할 대한민국 16기 대통령 故 노무현 님.

나도 나보다 어려운 사람들을 위해 무언가를 해야겠다는 다짐을 다시 한 번 굳게 해 본다. 구체적인 실천계획을 세워야 겠다. 내가 무엇을 할 수 있는지 부터...

- 2010년 5월 23일 : 위 글은 故 노무현 前 대통령 서거 당일날 썼던 글이다. 그렇지만, 그 당시 난 이 글을 공개하지 않았다. 내가 쓴 이 글이 부끄러워서 인지, 아니면 어떠한 불이익이 두려워서인지는 기억나지 않는다. 하지만 오늘 서거 1주년을 맞이한 지금, 이 글을 공개한다. 지금의 나에겐 1년 전과는 달리, 공개하지 못할 어떠한 이유도 없다. "우리는 노무현을 맞이할 자격이 없었다." 라는 글을 어디에선가 읽었던 기억이 난다. 서거 1주년이 된 오늘, 난 나에게 다시금 물어본다. "과연 지금의 난 노무현 맞이할 자격이 있는가? 그리고, 언젠가 또다른 바보가 나타났을때, 그를 맞이할 자격이 있겠는가?" 를...
(2010년 6월 2일, 지방 선거가 있다. 과연 이번은 어떨지...)

'물을 거울로 삼는 자는 자기 얼굴을 볼 수 있고, 사람을 거울로 삼는 자는 자기의 길흉을 알 수 있다.'고 합니다. 또 옛글에는 '성공했으면 그 자리에 오래 있지 말라'고 했습니다.
- '사기'(사마천)의 '채택열전' 중에서

내가 현재 처한 상황을 어떻게 알 수 있는가? 내가 앞으로 어떤식으로 처신해야 하는지 어떻게 알 수 있을까? '사기'의 '채택열전'에서 채택의 변론은 여기에 대한 답을 제시해 주고 있는 듯 하다. 채택이 응후에게 변론한 말 중 일부를 다시 한번 적어 본다.

"지금 당신의 군주가 충신을 가까이하고 옛 친구를 잊지 않는 점에서는 효공, 도왕, 구천만 못하고, 당신의 공적과 군주의 총애나 신임을 받는 정도 또한 상군, 오기, 대부 종만 못합니다. 그런데 당신의 봉록은 많고 지위는 높으며 가진 재산은 위의 세사람보다 많습니다. 만일 당신이 물러나지 않고 그대로 그 자리를 지키고 있으면, 당신에게 닥칠 근심은 세 사람보다 클 것입니다."

상군, 오기, 대부 종은 모두 큰 공을 세운 이후 군주로 부터 신임을 잃고 크게 해를 당한다. 채택의 변론은 이들을 거울로 당시 진나라의 재상이였던 응후가 취해야할 처세의 방향을 제시하고 있다.

나라고 다르겠는가? 나도 나와 비슷한 위치에 있는 다른 사람들을 거울로 보면, 내가 현재 처한 상황을 알수 있지 않을까? 그러면 자연스럽게 내가 취해야할 길도 알 수 있지 않을까? 그게 가능하기 위해서는 일단 여러가지 사례에 대해서 많이 알고 있어야 할텐데... 그래서 과거의 역사가 중요한가 보다. "과거를 통해서 현재를 안다."는 비단 국가의 존망, 역사, 성패 같은 거대한 흐름 뿐만 아니라, 작게는 내 자신이 성패, 상황, 처세를 읽는데도 중요하다는 것을 새삼 실감하게 된다..

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

어떤 사람을 회사에서 내 보내고자 할때, 어떻게 하는가? 그 중 하나가, "성취 불가능한 project에 자주 투입시키는 것"이라고 한다. ("회사가 당신에게 알려 주지 않는 50가지 비밀" - 산시아 샤피로). 뭐.. .실제로도 그렇게 보인다. 그렇게 해서, 그 사람으로 하여금 회사에 정나미가 떨어지게 만들어, 제 발로 걸어나가게 만들 수 있으니까.

그렇다면, software개발에서는?

거의 모든 회사에서, software개발의 schedule은 항상 overly optimistic하다. 또한 상당부분, overly optimistic을 넘어 impossible한 경우가 많다. 그래서 어느 순간에는, software 개발 schedule이 나오더라도, 당연히 못 지킨다고 생각하고 마음을 비우게 된다...-_-; 그렇다면, SW회사는 software engineer를 회사에서 떠나보내게 하려고 그러는 것일까? 물론 아니겠지만.... engineer는 떠나고 싶어진다... 문제는.. 안 그런 곳을 찾기가 어렵다는 것인데... 씁쓸하다...

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

필자가 국내 핸드폰 소프트웨어 개발 직종에 종사하면서, "이건 아닌데..."라고 생각한 부분이 몇가지 존재하는데, 그 중에 하나가 Test & Debugging Cycle에서의 문제점이다.
필자가 경험한 바로는 Test & Debugging Cycle에서의 업무는 다음과 같이 이루어 진다.

1. Test engineer(이후 TE)가 발견한 버그를 Issue Tracking system에 기록한다.
2. Engineer가 이를 보고 실제 재현을 해 본다.
3.1 문제없이 재현하였다면,   이게 정말로 버그인지 아닌지 확인한다.
3.2 재현에 실패했다면, TE에게 재현 방법을 물어보고, 3.1의 과정으로 간다.
4. 실제 버그가 맞다면, 수정에 들어간다.

그런데, 문제는 위의 과정에서 생산성을 저하시키는 일들이 필요이상으로 많이 발생한다는 것이다. 하나씩 살펴보자.
먼저, 1과 2사이를 보자.
보통의 경우 - 국내 업체 -  Product Specification, User Interface Specification(이후 UIS)같은 문서들이 대부분 상당히 부실하게 작성되어 진다. 이 중에서 SW측면에서 보았을때, 특히 중요한 것이 UIS인데, Specification이라는 이름에 걸맞지 않게 허술하게 작성되는 경우가 대부분이다. 필자의 소견으로는, 기업이 이 부분에 크게 투자하지 않는 것 같다.  SW를 경시하는 만큼 UIS도 경시하는 듯 하다. 따라서, TE입장에서는 무엇이 버그이고, 무엇이 버그가 아닌지 판단할 수 있는 확고한 근거가 없으므로, 그냥 본인이 이상하다고 생각하면 전부 버그라고 reporting하게 된다.

2와 3 사이의 경우, TE의 reporting미숙에서 오는 overhead가 상당히 크다. 개발자들은 bug report을 보고, 이를 어떻게 재현할 수 있는지 몰라서, TE에게 찾아가거나 혹은 전화로 다시 한번 확인하는 경우가 태반이다. 심지어는 "xxx를 하면 화면이 이상하게 보임." 이라고 기록된 어이없는 reporting을 본 적도 있다. 이는 TE의 역할에 대한 기업의 잘못된 정의가 가장 큰 원인이라고 필자는 본다.
보통  QA를 TE의 역할로 정의하는 업체가 많다. 물론, QA는 TE의 가장 중요한 역할 중 하나이지만, 국내의 경우 그 정도가 지나친 것처럼 보인다. 무슨 말이냐 하면, 오로지 bug를 찾아내는데만 TE의 역할이 집중되어 있다는 뜻이다. 보통의 경우, TE의 임금은 Developer에 비해 저렴하다. 그래서 TE라는 직종이 따로 생겼고 (만약 그렇지 않다면, developer가 TE의 역할을 같이 겸하게 되었을 것이다.)  SW의 bug를 찾고 품질을 검증하는 역할이 주어졌다. 그렇다면, 상대적으로 비싼 비용이 드는 Developer의 시간을 절약하고 이 역할을 TE가 해 줄 수 있도록 해야하지 않겠는가? 따라서 debugging을 위해 developer를 support하는 것 역시 TE의 중요한 역할 중 하나가 되어야 하고, TE의 성과 평가 항목에 반드시 이 부분이 반영되어야 한다. 이때, 가장 기본적인 것이 bug reporting이다. TE는 bug를 재현할 수 있는 방법을 명확하게 기술해야 하고, debugging에 도움이 되는 정보를 추가적으로 기록해 줄 필요가 있다. 에를 들면 아래와 같다.

menu -> setting -> time & data -> 24시 format으로, 12:00를 setting하면 phone이 reset됨.
menu -> setting -> time & data -> 12시 format으로 12:00를 setting하면 정상 동작함.
menu -> setting -> time & data -> 24시 format으로, 11:00를 setting하면 정상 동작함.

이런 정도의 reporting은 상대적으로 비싼 비용이 들어가는 Developer의 시간을 상당히 절약시켜 줄 수 있다.  물론, 너무 상세한 reporting으로 인해 쓸데 없이 많은 시간이 소모된다면, 그것 역시 피해야할 것이다.
좋은 TE를 유지하는 일은 상당히 어렵다. TE라는 일 자체가 가지는 특성때문에, 좋은 TE는 빨리 다른 직종으로 이직하고자 하기 때문이다. 따라서, 어떻게 좋은 TE를 유지할 것이냐 또한 심각하게 고민해할 문제이다.