생산성 낮은 프로그래머
글쓴이: joone / 작성시간: 화, 2006/05/23 - 10:48오후
생산성 낮은 프로그래머의 특징
1. 코딩 스탠다드나 설계 표준을 지키지 않습니다.
2. 다른 사람이 작업한 결과와 자신의 코드를 통합하기전에 버그를 다 수정하지 않습니다.
3. 자신의 일에 관해 예측을 잘 못합니다.
연구결과 전문 개발자의 10%가 이런 부류에 속한다고 합니다.
가끔 가슴이 뜨끔합니다. 공부합시다.
참고문헌
[1] Steve McConnell, Professional Software Development, 2004, p137-138
File attachments:
| 첨부 | 파일 크기 |
|---|---|
 low_programmers.png | 92.61 KB |
댓글
경험없는
경험없는 초보개발자들로써는 저러면서 배우는거 아닐까요?
쌩~날~초보에게 생산성자체만을 강요하는건 문제가 있는듯한뎅~ :)
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
쌩~날~ 초보에게는
쌩~날~ 초보에게는 오히려 그런 식으로 일하는게 더 생산성이
있는거 같아요. 같이 일하는 사람은 조금 괴로울지 몰라도... ^^;
----
재미없는 일은 하지 말자는 인간 쓰레기.
-.-;
--------------------------------------
재미없는 일은 하지 말자는 인간 쓰레기.
-.-;
음... 저는 10%에
음... 저는 10%에 속하는 것 같네요.
그나마 다행인건 제가 전문개발자가 아니라는 사실입니다. :-)
------------------------------
좋은 하루 되세요.
------------------------------
좋은 하루 되세요.
큰일이군요.
전문개발자의 90%는 저런 부류에 속하지 않는걸까요.
노력해야겠습니다; 중간이라도 하려면요 ^^
--------------------------
The universe is run by the complex interweaving of three elements: matter, energy, and enlightened self-interest.
- G'kar, Babylon 5
-------------------------
The universe is run by the complex interweaving of three elements: matter, energy, and enlightened self-interest.
- G'kar, Babylon 5
계약 시 개발기간도
계약 시 개발기간도 짧게 잡고
실제 개발시간은 더 짧게 주고
정해진 개발시간에 하는 일중 많은 시간이
쓸데없는 문서작성 및 회의에 쓰이는것도 문제라고 봅니다.
10%를 제외한.. 이 맞지 않을까요? ^^
제 체감상으로는 개발자의 10% 정도만이 생산성이 높은 프로그래머라고
생각되는데요..^^;
한명의 뛰어난 프로그래머의 생산성이 그렇지 않은 경우의 10배의 생산성을
얻는 경우가 많다고도 하구요(이건 진짜입니다..)
소프트웨어 개발 업무 자체가 인간의 복합적인 사고 능력을 기반으로 하고
있어 생산성이라는 공장 개념과는 잘 맞지 않는게 원인일 듯..
모두 좌절하지 마시고 희망을 가집시다..^^;;
http://blog.dreamwiz.com/shjii
네, 저도 오리님의
네, 저도 오리님의 말씀에 동의합니다.
하지만 저두 저 10%의 항목을 모두 지키며
4. 웹서핑, 채팅
5. 담배피러 자주 나가기, 나가서 수다도 떨기
6. 잠들기(조는 정도가 아님)
정도의 항목도 지켜주므로 저 10%의 상위 10%에 들지 않을까 합니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
제가 볼때는
제가 볼때는 생산성이 낮은 프로그래머 라고 할일이 아니라..
생산성이 낮은 시스템들이 더문제입니다.
과연그것이 얼마나 비생선적인 결과를 초래하고 있는지 알고 있는지..
가끔 그런생각을 해봅니다 도데체 무엇을 위한 또 누구를위한 표준이고.. 도큐먼트인지..
----------------------------------------------------------------------------
저런 특징을 찾기 전에..
저런 특징이 발생하는 원인을 찾는게 순서라고 봅니다.
위에 말씀하시는 것처럼,
일반적으로 가능하지 않은 시간과 요구를 맞추려다 보면,
당연히 결과로만 판단을 하게 됩니다.
프로그램에 대해서 상세히는 아니더라도,
어느 정도 예측 할 수 있는 leader 가 있어야,
진실한 생산성 낮은 프로그래머의 특징을 가늠할 수 있다는 생각이 듭니다.
진행 일정 만들어 놔봐야, 중간 interupt 시간을 추가해주는 갑 도 없고,
그렇다고, 프로젝트 마감 시한 지키지 않으면,
예외적으로 발생한 추가 업무량에 대한 감안과 아무런 대책도 없고,
다만, 기한을 넘긴 질책만 있는 현실입니다.
좀 지루한 코멘트입니다...
1. 코딩 스탠다드나 설계 표준을 지키지 않습니다.
2. 다른 사람이 작업한 결과와 자신의 코드를 통합하기전에 버그를 다 수정하지 않습니다.
쉽게말해 "시키는 일은 안한다"는 얘기군요.
혹시 여러분들 주변에 작업표준 안지키거나 단위테스트 안하고 연동하는 개발자들 있습니까?
(저는 이런 경우를 한번도 본적이 없습니다. 여러분 주변에도 거의 없으리라 확신합니다만)
오히려 어설프거나 비효율적인 작업표준을 강요받는 곳들이 대부분일거라 생각됩니다.
아무튼 이런 개발자는 하위 10%정도가 아니라 업계퇴출입니다.
3. 자신의 일에 관해 예측을 잘 못합니다.
은행 한곳에서 5년이상 pro*c만 주구장창 하는 개발자들도, 소위 잘나가는 DB전문가라는 사람들도
국내 유수의 bmt현장에서 제대로 자신의 일에 대해 예측을 제대로 못합니다.
(늘하던 일이 아니라 새로운 환경에 레퍼런스도 없는 상황이라면?)
약간 웃기는 이야기를 하자면, "정해진 범위의 작업에 대한 기간의 예측"보다는
"정해진 기간 내에 가능한 범위를 조율"하고 이를 포장하는 것이 오히려 더 중요합니다.
(여담이지만 여러분은 실제로 Microsoft Project를 어떻게 설정하세요? ^^ )
개인의 작업이든 회사의 프로젝트든 모두 해당되며 외국인들한테도 잘 통하는 수법입니다. ^^
homeless
'생산자' 가 되긴
'생산자' 가 되긴 싫은데..
----------------------------------------------
Fly me to the moon, and let me exit the world.
화이팅(fighting) 말고 화이트닝(whitening) 하면 안되나요.
밑의 사람이 어리버리한 것보다 윗 사람이 어리버리한게 더욱...
스탠다드를 아무리 잘 지켜도 문제가 생기는 경우가 있죠.
아무리 아래서 일을 잘해도, 윗 사람이 방향을 잘못잡아서 back 해야 되는 경우에
생산성은 정말 바닥을 기어다니죠.
사실 아무리 개별적인 profiling 을 거친다고 하더라도 전체 밑그림이 틀리면 원체 성능이 안나오기도 해서
다시 만들기도 하더군요.
전 우리나라 SI 에서 가장 의문시 되는게 성능이 안나오면 왜 안나오는지 분석하기보다
결국은 하드웨어로 커버할려는 도둑심보가 가장 의심이 가더군요. 마치 을과 HW 업체와 짜고치는 듯한...
그래서 일부러 초급을 쓰는게 아닌가 하는 생각이 듭니다.
========================================
* 부분이 전체를 대변하는 하나의 속성일때 진리이다.
영속적이지 못한 것은 전체가 될 수 없다.
========================================
* The truth will set you free.
상당부분 동의
상당부분 동의 합니다.
비효율적인 부분을 요즘하드웨어가 좋기때문에 걱정마라식으로 넘어가죠..
건축가는 설계하고 목수는 자기의 노하우로 구현을 하면되는데..
건축가가 설계는 날림으로하고 목수의 노하우대신에 자신의 노하우를 주입하려하니...
----------------------------------------------------------------------------
생산성입니다. 같은
생산성입니다.
같은 일을 하는데 있어서
S/W를 개발하는데 100만원이 듭니다.
H/W를 납품하는데 50만원이 듭니다.
이럴경우 H/W를 납품하게 됩니다.
그걸 도둑심보로 보기는 힘듭니다.
을에서도 H/W를 납품해서 이익을 덜 남기는 것보단
자체 해결해서 이익을 더 남기려고 하지 괜시리 H/W를 구매해서 손해보는 장사를 하려하지 않습니다.
장기적인 생산성을 봐야 한다고 봅니다.
개발자로서 별로 생산적인 스타일이 아니라 할말은 없지만, 핑계삼아 주장해 보고 싶습니다.
이번 프로젝트에서는 H/W를 납품하는게 50만원이면 되지만 다음, 그다음에도 계속 누적된다면 이번에 100만원을 들이고 비록 앞으로 몇번 더 들일수도 있지만 그렇게 해서 S/W개발의 생산성을 최대한 끌어올리는게 결국엔 좋지 않나 생각됩니다.
최소한 기업이나 국가는 장기적인 생산성을 봐야 한다고 봅니다.
제가 심한 불평불만 비관주의자 거든요. ^^
신라의 달밤 명대사를 아주 좋아합니다. 예비군 훈련 통지서 받고 건달 두목이 한 말 같은데..
'국가가 나한테 해준게 뭐가 있는데!!'
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
H/W는 단종 되지 않는
H/W는 단종 되지 않는 이상 가격은 점차 내려갑니다.
H/W는 단종되면 그것을 커버하는 신상품이 나옵니다.
1번의 프로젝트에서 H/W를 납품했다고 다음 프로젝트에서 H/W를 납품하라는 법도 없습니다.
장기적으로 본다면 프로젝트를 여러번 진행하면서 생긴 노하우로 S/W를 더 발전시켜서 생산성을 높이면 됩니다.
하지만 지금당장 S/W의 생산성을 끌어올리기보단 장기간 여러번의 프로젝트를 통하여
점진적으로 올리는게 회사에 무리가 안가고 좋다고 봅니다.
p.s. 제가 아직 어려서 SI업체치고 같은 프로그램 여러번 납품하는 경우를 못봤습니다. 이 점 참고하시고 제 의견을 받아들여주셨으면 합니다.
네, H/W의 가격이
네, H/W의 가격이 내려가는걸 생각 못했네요. ^^
회사의 입장에선 비용(생산성)이 가장 중요하다는 생각은 저도 같습니다.
물론 회사와 개인의 이해충돌이란건 있겠지요.
제가 말씀드린 S/W의 생산성 향상도 한번이 아니고 점차적으로 늘려야 하는건 저도 같은 생각입니다. 그리고 제가 생각하는 생산성의 향상은 개발자의 스킬업, 잘 만들어진 재사용 가능한 라이브러리나 프레임웍, 미들웨어, 그 과정에서 생긴 노우하우들의 도큐먼트 정도라고 보시면 될것 같습니다.
결국 제 의견은 오리님의 의견에 반론을 제기했다기 보다는 그냥 개발자로서 사회생활을 하면서 생긴 '불평불만' 정도로 보시면 됩니다. 국가에 대한 불만도 동일하구요.
실제 제가 경험한 바로는 H/W의 비용으로 커버를 하면서 S/W의 비용은 거의 무시하는 경향의 회사들이 많은것 같아서 말씀 드렸습니다. 둘의 밸런스가 잘 맞아야 회사도 개인도 좋을텐데요. 그런회사가 없는건 아닐테지만 제가 운이 없어서 그런지 실제 다닌 회사는 그런 곳이 없었습니다. 아, 처음 자바를 배우게 된 회사는 제외해야 겠네요. 그곳에서 제 사부를 만났었으니까요.
제가 일한 결과물은 나중에 거의 쳐다도 안보게 됩니다. 제가 얻은 지식은 남한테 잘 알려주지도 못하구요. 경력은 7-8년차가 되가는데 이런 상황이라 책임을 회사에 돌리고 싶은가 봅니다.
저는 제가 나이가 많거나 경험이 많다고 생각하지 않습니다. 큰 규모의 SI는 해본적두 없구요. 다만 더 발전하고 배우고 싶은데 그럴 기회나 가능성이 점점 줄어드는것 같아서 그러나 봅니다.
이 일을 나이 많이 먹어서도 하고 싶으니까요.
그냥 제가 지금까지 경험한것과 여러 간접 경험을 바탕으로 한 생각(+불만)을 올린 글일 뿐이구요.
저두 어리다구요. 오리님이 저보다 나이가 많으실수도 있는데요.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
저는 전문
저는 전문 프로그래머가 아니라 여쭙는건데
보통 프로그래밍을 하는데 있어서
구성원 각 개인의 능력(개인기)과 팀워크 중 어느쪽이 생산성 향상에 비중이 더 높은가요?
The knowledge belongs to the World like Shakespear's and Asprin.
과감히 제 생각을 말씀드리자면...
팀 프로젝트에서는 팀워크입니다.
10명중 1명이 천재라서 10명이 할 일을 혼자서 한다해도
팀워크가 안맞으면 천재도 바보가 되어버립니다.
* 팀웍과 개인기를
* 팀웍과 개인기를 말씀하셨는데, 둘 다 중요합니다. 때에 따라, 팀웍이 필요한 순간이 있고, 때에 따라 개인기가 필요한 순간이 있기 때문입니다. 어느 하나도 놓지게 되면 회복하기는 힘들기 때문에 항시 유지/개발(발굴?/연마?)에 신경써야 하는 부분입니다.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
이 만화를 그린 이유는...
저도 경험이 많은 개발자라고 생각했지만 (여기서 말하는 전문 개발자...)
간혹 10%의 생산성 낮은 개발자라는 생각이 들기도 합니다.
여러 사람이 함께 개발할 때는 좀 더 코드에 책임을 지고, 합의한 방향과 방법에 맞게 개발을 진행해야 하는데, 완전히 따로 노는 경우가 있죠..
좀 더 정신차리자는 의미로 그려봤습니다.
_________________________
http://joone.net
https://kldp.org/blog/2725
http://opensoftware.tistory.com
http://joone4u.blogspot.com
https://gnome.or.kr
직접
직접 그리신건가요?
캐릭터가 귀엽네요
저는 그림하면... 피카소 화풍을 따르는 편이라... ㅜㅜ
The knowledge belongs to the World like Shakespear's and Asprin.
HW 비용을 우습게 볼게 아닙니다.
욕심많은오리 님의 말씀대로 하드웨어가 싸면 그렇게 하는게 맞습니다.
그러나 대부분의 공공쪽 SI에 투입되는 하드웨어는 가격이 만만치 않습니다.
대부분의 유닉스 머신들을 도입하는 경우에, 그 가격만해도 몇십억을 넘어갑니다.
예를 들어 IBM의 p690은 24way 만 해도 가격이 20억원에 달합니다.
Sun의 15K나 HP 의 수퍼돔같은 경우도 거의 비슷한 가격에 육박하죠. 아무리 price off를 해도
백업용까지 한 서너대 사주면 아주 엽기적입니다.
많은 PM 들이 하드웨어 가격은 내려간다.
그러므로 가만히 있어도 성능은 좋아진다고 거짓말을 합니다.
그러나 실제로 그런가요? 하드웨어가 좋아졌다고 인터넷이 더 빨라지는 것은 아닙니다.
오히려 처리하는 데이터가 늘어나서 피장파장이 됩니다.
저도 나이가 그다지 많지 않아서 절대적이라고 말할 수 없지만, 대부분의 공공이나 대형사이트는
도입후 처리용량이 늘어나는 속도가 하드웨어의 발전속도보다 훨씬 빠르더군요.
우리나라 메이저급 포털은 늘어나는 데이터를 감당하지 못하는 것과 비슷합니다.
========================================
* 부분이 전체를 대변하는 하나의 속성일때 진리이다.
영속적이지 못한 것은 전체가 될 수 없다.
========================================
* The truth will set you free.
하드웨어 비용이 싸다니.. 좀 잘못된생각입니다.
하드웨어비용이 싸다니요..
하드웨어는 조금만 업그래이드할려고해도 수천만원에서 수억듭니다.
소프트웨어요.. 예를들면 기존프로그램을 1달간걸쳐 성능개선한다고 해봅시다.
몇백만원의 비용이죠..
물론 얼마나 개선할곳이 많은가에따라 상당히 개선될수도.. 아니면 크게 개선되지 않을수도 있지만.
그건 개선할수 있을지 없을지 애초에 잘판단해야겠죠..
그러나 대부분의 프로그램들이 많은 개선이 필요할것같은데요..
----------------------------------------------------------------------------
하드웨어에 대한 ROI가 가시적이다라는 말은 어떨지?
기술적 문제라기 보다는 재무적문제인데요.
소프트웨어를 개선해서 효과를 얻는 부분에 대해 재경쪽 인간들
설득하는게 상당히 어렵습니다. 일단 소프트웨어 개선이라는 것 자체가
기술적지식없이 이해하기가 어렵고, 그래서 얼마나 개선이 되는데라는
태클들어오면 효과산출(그것도 돈으로)하기 대단히 어렵습니다.
소프트웨어기술과 재무적지식(그것도 쉽지않은 Finance Planning에 대한 지식)을 모두 갖춘 사람이 있어야 이런종류의 일이 무리없이 굴러갈수 있는데, 실제로 이런 사람은 극히 드문게 현실입니다. ( 뭐 이런 사람이 굳이
소프트웨어분야에 있으려 하지도 않을거라고 생각하는게 제 개인적인
의견입니다만. 아마도 회계법인 갈려고 하지 않을까요? )
반면에 하드웨어에 돈 들이는건 이해하기가 쉽습니다.
소프트웨어가 어떻든간에, 더 좋은 하드웨어 들여놓으면 효율성은
둘째치고 성능이 올라는 가거든요.
재경쪽 인간 설득하기도 쉽고, IT에 대한 커다란 지식이 필요하지도 않습니다. ( 엄밀히 말하면 Capacity Planning이 제대로 되어 주어야 하나,
현실은 별로 그렇지 못하죠. 항상 보면 CPU 8장 이런식이니까요. )
정리하면 소프트웨어에 대한 ROI는 전문가가 아니면 대단히 비가시적입니다만
( 그래서 도무지 설득이 안됩니다. ), 하드웨어 대한 ROI는 상당히 가시적입니다. ( 특히 돈줄쥐고 있는 사람들한테 )
그래서 하드웨어 투자가 소프트웨어에 비해 쉽게 이루어지는게 아닐까합니다.
컨설팅 업계가 그래서 욕을 먹지요.
brianjungu 님이 콕 집어주신 것처럼 문제의 본질은 가시적이냐 비가시적이냐에 있습니다.
아주 정확하게 찝어주셨는데요.
이런 가시적인 효과 산출을 위해서 원래 컨설팅 그룹과 일을 하는 것인데,
대부분의 컨설팅 그룹은 블라인드처리된 협의과정에서 과도하게 SW의 생산성에 대한 부분을
일축하고 HW 투입을 장려하는게 대부분이었습니다.
그래서인지 오히려 컨설팅펌이 왔다가면, 하드웨어의 대규모 투자가 이뤄지죠.
그것도 어떤 컨설팅펌인가에 따라서 사용되는 하드웨어나 정책도 항상 같습니다.
(어찌보면 컨설팅 펌이 자동차 영업사원과 다른게 없다는... -_-;;)
대부분 짜고치는 고스톱이라는 게 여기서 나오는 말이죠.
물론 본질적인 문제는 이런 것을 제대로 잡아내지 못하는 갑의 기술력이기도 합니다만,
우리가 한우를 살때 그 한우고기의 전문가가 될 필요가 없어도, 믿고 사는 신용이 있기 때문인데,
매번 거짓말 하면, 신용문제로 바뀌죠. 이때쯤 되면 서로가 막가는 상황인데, 국내의 SI 업계가
결국 이 상황까지 오게 만들더군요.(요새 서로 너무 못믿습니다)
그래서 요새는 서로가 서로를 신용하지 못하다보니 갑도 비밀리에 고급 기술자와 계약하여
을과의 미팅에 자사 직원처럼 속여서 데려갑니다. 여기서 을이 거짓말하거나 하는 것을 몰래 캐치해서
내부자료로 가져가는 것이죠. 이게 쌓이고 쌓이면 결국 SI 업체들도 나중에 좋을게 없는데 말이죠.
이런 이유로 최근 갑들도 을이 하는 이야기 거의 50%이상은 뻥이라고 생각합니다.
오히려 실력이 검증되지 않은 외국계를 더 믿더군요. 다 인과응보라고 생각합니다.
솔직히 공공부분의 눈먼돈 아니였음 국내 SI업체 옛날에 다 망했을겁니다.
========================================
* 부분이 전체를 대변하는 하나의 속성일때 진리이다.
영속적이지 못한 것은 전체가 될 수 없다.
========================================
* The truth will set you free.
플래시 버전
플래시 버전 - 텍스트 변경가능 - (소스보기)
대단하십니다.
대단하십니다. 플래시로 보는 것도 색다르군요.
댓글 달기