quality

개밥 먹기(Eating one's own dog food)

얼마 전에 했던 생각인데 아직 파트장등에게 제대로 제안을 해 보지는 못한 아이디어 하나. Rephrasing 하려고 했다가 그냥 도비호님 포스트에 적은 댓글을 그냥 옮겨왔다. 분야는 다름니다만 저희 팀이 S/W 인력만 100명이 넘는 지라 여러 작은 팀으로 나뉘어져 있고, 그 덕(?)에 부서간 알력이나 협조가 안되는 경우가 무척 많습니다. 그리고 문제가 생겨 디버깅을 하다 보면 남의 파트의 로그나 디버깅 기능을 이용하는 경우가 많은데 무척이나 불편한 경우가 많습니다. 솔직히 그 담당자가 봐도 해석이 어려운 로그가 많더군요.

20 Famous Software Disasters

초난감 기업의 조건에 나올 만한 사건들 20 Famous Software Disasters, Part 2, 3 and 4 via DevTopics Mission-critical software일 수록 정말 조심해서 프로그램을 만들어야 한다. 하지만 우리가 하는 일이 mission-critical이 아니라 할 지라도 단 하나의 버그로 인해 초래될 수 있는 현상은 그 회사의 이미지를 바닥으로 내동댕이 칠 수 있다는 점을 반드시 기억해야 한다. 주변을 보면(물론 나도 포함해서) 너무 쉽게 프로그래밍하고, 너무 쉽게 버그를 생각하는 경향이 있다. 그런 사람들은 현장에 나가 고객을 한번도 만나보지 못한 경우가 많다.

collaboration

Collaboration is a structured, recursive process where two or more people work together toward a common goal—typically an intellectual endeavor[1][2]that is creative in nature[3]—by sharing knowledge, learning and building consensus. Collaboration does not require leadership and can even bring better results through decentralization and egalitarianism.[4]In particular, teams that work collaboratively can obtain greater resources, recognition and reward when facing competition for finite resources.[5] http://en.wikipedia.org/wiki/Collaboration Though good collaboration doesn’t guarantee a project’s success, poor collaboration almost always guarantees a project’s failure.