SW 개발 문화

부정하기 어렵다. 하지만 코드가 늘어나는 것은 피할 수 없으니 불필요한 기능/코드는 삭제하는 노력을 끊임없이 해야 한다. 그렇지 않으면 technical debt만 늘어날 뿐이다. 개발할 때는 제대로 이해하고 만들어서 technical debt가 아니었더라도 시간이 지나 동작하지 않는 코드가 되면 불필요한 짐만 된다.

누군가의 말을 빌리자면 품질 관리의 바이블(?)이라고 하는. 내용면에서는 특별한 건 없지만, 그래도 국내에서는 SW를 잘한다고 하는 사람들이 많이 가는 회사이고, 누구못지 않게 SW 문화가 좋을 거라고 생각하는 회사라 어떤 고민을 하고 어떻게 SW 품질을 위해 노력하는 지 알 수 있게 해주는 유일한 책이다. 외국의 많은 회사처럼 사내에 노하우 등을 많이 공유하는 좋은 모습을 보이고 있고, 실제 제공되는 서비스의 독점성이나 중립적이지 못한 언론 관련 내용은 맘에 들지 않지만 그래도 개발자 입장에서는 이렇게 현실적인 내용을 공유해주는게 감사할 따름

잘못된(?) 진단은 잘못된 처방을 낳는다. 모든 걸 개인의 잘못으로 돌리려는 의도는 의외로 단순. 잘못을 저지른 개인은 개선시키면 된다는 단순한 해법을 제시할 수 있으므로. 개인을 구박하거나 심지어는 그 조직에서 제외시키면 문제가 해결(?)되는 것처럼 보이니까. 하지만 그 뒤에 숨어있는 실은 개인의 잘못으로 돌려진 관리의 문제, 시스템의 문제는 아무도 건드리지 않는다. 문제의 원인이 너무 커서, 문제의 원인이 너무 근본적이라, 문제의 원인이 권력자에게 있는 터라. 그렇게 문제는 반복된다. 비난의 대상이 되는 ‘개인’만 바뀔 뿐. 병든 조직은 서서히 그렇게 스러진다…

관리자들이 개발자들을 위해 한 일이 뭐가 있나? 아무리 생각해도 잘 모르겠다. 그럼 개발자를 위한 사람이나 제도는 없다는 건데 그러면서 개발자가 잘 하기 기대하는 건 도둑놈 심보가 아닌가? 자꾸만 벗어나길 원하는 ‘개발’업무를 만든 게 누구인지? 왜 그렇게 된 건지? 이런 근본적인 질문에 대한 고민과 해결 없이 SW품질을 논한다는 건 어불성설이다.

규제를 풀기 어려운 이유는 그 규제를 풀어도 문제가 없는 지 자신이 없기 때문이다. 증명하기 어려운 경우가 대부분. 하지만 머리를 맞대고 함께 이야기해봐야 한다. 정말 필요한 절차인지 고민해야 한다. 가능하면 절차는 줄이고 또 줄여야 한다고 생각. 이런 고민조차 어려운 이유는 대부분 한 쪽이 들으려 하지 않기 때문. 기존에 하던 (불필요해보이는) 절차를 없애는 경우 발생할 수 있는 위험요소를 감수할 의지가 없으므로. 혹시 이렇게 생각하고 있는 건 아닌지 그런 번거로운 절차는 내가 하는 게 아니라 니들이 하는 거니까

From http://www.theeffectiveengineer.com/blog/what-makes-a-good-engineering-culture 1. Optimize for iteration speed Continous deployment to support rapid validation High test coverage to reduce build and site breakages Fast unit tests to encourage people to run them Fast and incremental compiles and reloads to reduce development time Bill Walsh, 49ers to 3 Super bowls, Commit, Explode, Recover A team crippled with indecisiveness will just cause individual efforts to flounders 2. Push relentlessly toward automation Consider operational burden per engineer

어딘가 보고 정리한 글인데 출처를 기억하지 못하겠다…. SW 품질 개선 노력의 대상 SW 품질을 높이는데 Tool, System, People 그리고 Management중에 어떤 면을 개선하는 경우 효과가 높을까? Tool : 2 배 System : 10배 People : 30배 Management : 60배 이상 그렇지만 대개의 관리자는 개선효과를 반대로 알고 있다. 사람은 변화해야 할 때 변화한다(더 이상 저항하지 못할 때) 그러나 위기는 갑자기 오지 않는다. 다만 위기에 대한 인지를 갑자기 할 뿐이다. 변화는 성능 저하를 유발한다.

경쟁을 부추켜서 조직의 성과를 얻으려는 관리자는 아무런 노력도 하지 않고 결과만 날로 먹으려는 것과 같다. 아무 고민없이 할 수 있는 제일 쉬운 방법이니까. 조직원들에게 동기부여를 줄지, 조직의 협동심을 아떻게하면 높일 수 있을 지 고민할 필요가 없이 결과만 취하면 되니까. 그런 관리자는 조직에 해를 끼치는 존재다. 할 수 있는 게 없는 건지,해도 안되는 건지. 여러가지 방법을 써도 안된다면 조직원과 함께 고민하면 안될까. 함께 속해 있는 ‘조직’의 성과를 위한 거니까 @유정식의 ‘착각하는 CEO’를 읽는 중 프랑스/베트남/쥐 박멸/쥐 사육 부분을 읽고

정말 하나같이 핵심적인 내용인데 정작 이걸 알아야 하는 사람은 이런 데 관심이 없겠지. 출처 : 부실한 공유문화를 지배하는 개발자의 심리 전반적으로 공유문화가 부실하게 된 것은 현재 개발자들의 책임은 아니다. 원래 문화라는게 우리의 선조, 선배들이 만들어 놓은 것을 따르면서 아주 약간씩 바뀌는 것이다. 개발문화도 그렇다. 지금까지 선배들이 그런 환경에서 그렇게 일해 왔기 때문에 그런 문화가 형성되었고 우리도 거기에 적응해서 일하고 있는 것이다. 문화가 바뀌기 어려운 이유는 나 혼자 노력해서는 안되기 때문이다. 다른 사람들은 공유를 위해서 노력하지 않고 나 혼자 애를 쓰면 나만 두배로 손해를 본다.