소프트웨어 개발에서 최악의 거짓 경제는 무엇입니까? [닫은]

126

소프트웨어 산업에서 가장 나쁜 거짓 경제는 무엇입니까 (즉, 궁극적으로 저축하는 것보다 비용이 많이 드는 돈을 절약하는 방법) 그리고 어떻게 싸워야합니까?

programming-practices project-management

— Jon Hopkins
소스

2

:( 나는 이것들을 너무 자주 보았다.

— Tony

3

관련 programmers.stackexchange.com/questions/18585/…

— cmcginty

@Casey : 약간 관련이 있지만 완전히는 아닙니다. 이 질문에 대한 답변은 돈과 신념도 다루는 반면, 당신이 직접 돈을 다루는 링크는 여기에 있습니다. 예를 들어, 내 대답을 참조하십시오 : programmers.stackexchange.com/questions/19573/…

— Gan

방금 내 회사를 방문하셨습니까 .. 신경 쓰지

— 마라

1

@Mark-좋은 질문처럼 들리지요. 그래도 몇 가지 더 구체적 일 수 있습니다.

— Jon Hopkins

182

기술 부채

즉, "그냥 빨리하면 나중에 리팩터링 할 것"입니다. 첫째로, 나는이 행동에 관여하는 누군가가 실제로 나중에 리팩터링하는 것을 보지 못했기 때문에. 둘째, 빠른 방법으로 작업을 수행하기 때문에 좋은 방법 대신 미래의 기능을 추가하거나 향후 버그를 해결하기가 어려워 장기적으로 시간을 낭비하게됩니다.

안타깝게도 많은 사람들이 개발자주기를 단축하여 빠른 작업을 수행 할 수 있다고 생각합니다 . 가능하다고 생각하지만 실제로는 아직 보지 못했습니다.

— 이나이 마티
소스

2

관리 관리자가 하루 동안 개발자를 중지 한 횟수 (2 ~ 3)를 본 횟수를 계산 한 다음 배포 전문가가 2를 소비하는 대신 무언가를 수정하고 (제품 수명주기 동안 여러 번 수행) 횟수를 계산할 수 없습니다. 제대로하기 위해 4 일. 좋은 대답입니다.

— DevSolo

4

수정하는 데 걸린 시간을 달러로 측정 할 수있는 경우 (예 : 버그 수정 주식 거래 시스템) 관리 결정은 비용 절감을 향합니다. "이 문제가 다시 발생하지 않도록 올바른 수정 프로그램을 결정하는 동안 계속 실행하기 위해 지금 패치하십시오"는 비용 중심의 긴급 성을 충족시키고 올바른 결과를 얻는다는 것을 알았습니다. .

— JBR 윌킨슨

9

우리는 3 년에서 5 년 동안 진행해 온 기초에 있었던 "이것은 해킹입니다, 데모 후 교체"와 같은 주석으로 코드를 완성했습니다. 아무도이 시점에서 수행 된 것을 기억하지 못하므로 누군가 (me)가 버그를 수정하고 실행할 때까지 아무도 찾지 않습니다. 말할 필요도없이,이 실물 교훈은 내가 그렇게 할 수 있다면 처음에 올바르게하는 법을 가르쳐주었습니다.

— CodexArcanum

22

솔직히 말해서, 나는 짧은 시간을 절약하지 못하는 횟수에 지속적으로 충격을 받았습니다!

— PeterAllenWebb

6

@ 조지-허? "기술 부채와 디자인 부채는 슬래시 소프트웨어 아키텍처와 성급한 소프트웨어 개발의 결과를 언급하는 동의어, 신경 학적 은유입니다." en.wikipedia.org/wiki/Technical_debt 이것이 바로 내가 말하는 것입니다. 보다 구체적인 제목은 아마도하지만,이 상황에서 많은 사람들이 실제로 상환하고자하는 (그러나하지) 않는 자신에게, "그것은 상환 의도없이이 취해 기술 부채"이었을 것, 그리고 내가 원하는 펀치 에 넣어 제목을 상단에 굵은 글씨로 표시됩니다 . "기술 부채"는 충분한 요약으로 보입니다.

— Inaimathi

163

1 명 대신에 저렴한 개발자 2 명을 고용합니다 . (같은 가격)

— 사용자 2567
소스

9

이것은 적어도 현실에서 근거가있는 것 같습니다. 비 기술적 인 사람들은 위대한 개발자가 누구인지 알 수 없습니다 (따라서 실제 슈퍼 스타보다 무작위, 컨설팅 바보에게 두 배의 비용을 지불 할 가능성이 매우 높습니다).

— Inaimathi

112

또는 슬프게도, 1 개의 싼 것을 고용하는 것…

— DevSolo

4

... 또는 두 인형이 전문가의 급여의 1.0에 대해 전문가가하는 것의 1.5를 수행하는 전문가를 고용 : /

— bobah

14

당신은 더미에서 전문가의 75 %를 얻지 못하고 진정으로 훌륭한 프로그래머는 그것에 대해 코를 without 지 않고 필요한 것을 할 것입니다.

— 피터 Boughton

8

10x 또는 100x 프로그래머는 돈에 대한 놀라운 가치입니다. 그들은 아마 1.5 배 2 배를받습니다. Michael Lopp (Rands in Repose)에 따르면, 전체 경력에서이 중 하나만 고용하면 순이익입니다.

— Tim Williscroft

85

내 예는 NimChimpsky의 예 와 완전히 반대입니다 .

기성품을 구입할 수있는 사내 개발을 시도합니다.

일반적으로 이것은 실제로 시장을 점검하지 못하여 문제가 해결 될 무언가가 있는지 확인하기 때문에 발생합니다. 이것은 연구를하기 전에 코딩을 "다이빙"하고 싶어하는 개발자와 그 시간을 고려하지 않은 프로젝트 관리자, 즉 돈으로 인해 복잡해질 수 있습니다.

필자가 현장에서 본 가장 일반적인 예 중 하나 인 웹 개발은 자체 CMS 시스템을 개발하려는 회사입니다. 이것들은 항상 작게 시작되지만, 기능이 강화되면서 곧 부풀어 오르고 통제 불능 상태가됩니다. 항상 무료 제품과 프레임 워크가 많이 있기 때문에 훨씬 더 적합합니다.

— Dan Diplo
소스

17

그럴 수 있다고해서 꼭 그래야하는 것은 아닙니다. 기본 CMS입니다. 왜 휠을 재발 명해야합니까? 그러나 대규모 시스템에 대해 이야기하고 복잡한 비즈니스 프로세스를 모델링하기 시작할 때, 왜 사각형 구멍에 둥근 못을 설치하려고합니까? 특히 기존의 개발자와 기술을 보유하고있는 경우.

— NimChimpsky

9

@ NimChimpsky-두 가지 모두 유효한 예가 있다고 생각합니다. 나는 사람들이 비즈니스 프로세스를 깨뜨리고 그것들을 선반 소프트웨어에 맞추려고 노력함으로써 이점을 잃어버린 것을 보았지만, 개발자들이 방금 다운로드했을 수있는 "여기서 발명하지 않은"증후군 코드 문제로 고통받는 개발자들을 보았습니다. 그들에게는 더 재미있었습니다.

— 존 홉킨스

3

@NimChimpsky 사양에 맞춤 개발이 필요한 경우에는 문제가 없습니다. 작업을 계속 진행합니다. 사람들이 법안에 맞는 이미 개발 된 것이 있는지 먼저 확인하지 않고 개발에 직접 뛰어들 때 문제가 발생합니다. 작은 연구는 먼 길을 갈 수 있습니다!

— Dan Diplo

6

왜 바퀴를 재발 명합니까? 당신은 휠 엔지니어이기 때문에. 또는 당신의 바퀴가 다음 사람의 바퀴보다 낫기 때문입니다. 또는 바퀴가 맞지 않기 때문입니다. 참조 : mostlymaths.net/2010/03/…

— Derek

2

거의 모든 작업을 수행하는 곳에서 OTS를 구입할 수 있습니다. Fearless Leaders (tm)에 따르면 "우리 환경은 너무 복잡 하여 시장에서 처리 할 수 있는 것이 없기 때문에 거의 모든 것이 사내에서 다시 개발되었습니다 ." !! 그러나 헤이-청구서를 지불합니다. 우리는 어제 소프트웨어의 주요 구성 요소가 내년에 그래픽 인터페이스로 다시 작성 될 것이라고 들었습니다. 아아 아아아! 나는 모두 a-twitter ... (<pheh!>)

— Bob Jarvis

73

프로젝트 관리를위한 전용 리소스가 없음

나는 몇 명의 프로그래머가 계약을 맺었을 때 여러 번 경험했으며 이미 힘든 일을하는 사람이 프로젝트를 관리해야했지만 실제로 다른 작업으로 너무 바빠서 프로젝트가 실제로 추진력을 얻지 못했습니다. 프로그래머들은 "프로토 타입"과 물건을 만들었지 만, 리드 없이는 많은 것들이 바쁘게 보이기 위해 둥글게 달리고있었습니다.

새로운 프로그래머를위한 나쁜 장비

나는 한때이 정책이 "새로운 프로그래머들은 그들이 가치가 있다는 것을 증명할 때까지 작은 화면으로 아주 오래된 PC에서 작업해야한다"는 정책을 한 적이있다. 그러한 정책이 부정적인 선택을 일으켜 항상 더 건전한 환경에서 일할 수있는 선택을하는 좋은 사람들을 몰아냈다는 것은 놀라운 일이 아닙니다.

— 사용자 281377
소스

19

+1. 직원들에게 좋은 장비를 제공하지 않으면 "실패해야합니다."

— Terence Ponce

3

+1. 그러나 다음 사항에 유의하십시오. 많은 회사에서 하드웨어 예산은 인프라에 속하며 개발 예산과 별도로 유지됩니다. 인프라 관리자는 개발 관리자의 예산을 완화하기 위해 예산에 타격을 가하지 않을 것입니다. 나는이 불쾌한 정치가 여러 번 나오는 것을 보았습니다.

— 필

3

모든 프로그래머에게 나쁜 장비는 어떻습니까? 전 고용주는 5 년 전에 평범한 데스크톱에 코드를 작성하기 위해 실리콘 밸리 임금을 지불했습니다. 마감일이 지났기 때문에 1 년 전에 직원 절반을 해고했으며 7 월에는 나머지 직원 대부분을 해고했지만 소년은 장비 비용을 절약했습니다!

— 밥 머피

1

Kaz : 모든 개발자는 적절한 머신을 가지고 있어야합니다. 새로운 하드웨어를 구입한다는 것은 새로운 개발자의 PC가 다른 개발자의 PC보다 조금 더 낫다는 것을 의미합니다. 최악의 경우 스왑 머신이 크기가 큰 종족이라면 스왑 머신이 있습니다. 평범한 사람들은 효율적으로 일할 수있는 장비를 가지고있는 한 신경 쓰지 않을 것입니다. 내가 현재 일하고있는 곳에는 저를 고용 한 사람보다 더 새로운 (아마도 더 빠른) PC가 있습니다. 나를 따라온 사람들은 더 새롭고 더 빠른 PC를 가지고 있습니다. 맞춰봐? 우리의 모든 기계가 충분히 빠르기 때문에 아무도 신경 쓰지 않습니다.

— user281377

3

하드웨어가 부적절 할 때 나는 보통 발톱을 자르거나 긴 컴파일 중에 종이를 읽는 것과 같은 유용한 작업을 수행함으로써 경영진에게 알려야한다. 오래된 느린 기계를 얻습니까? 물론이지. 오, 당신은 러시 버그 수정을했고, 나는 한 빌드를 할 수있어? 물론, Mr-Manager-bwana-sahib-dude-나중에 90 분 후에 만나자! (매일 관리자가 하루 종일 무엇을했는지 물어 보았습니다. 저는 그에게 "앱을 다시 빌드했습니다. 4 번". "8 시간 안에?!?"라고 소리 쳤습니다. . 즉 :-) ... 새로운 기계가 나타났다 얼마 후 "10 시간이 걸렸다

— 밥 자비스

71

프로그래머를 테스터 / 기술 작가로 두 배로 늘려서 비용을 절약 할 수 있습니다

테스터 / 기술 작가 작업에 대해 프로그래머 급여를 지불하는 경우, 해당 작업에 경력을 바친 사람보다 돈을 낭비하고 품질이 낮은 작업을 수행 할 수 있습니다. 또한, 프로그래머가 엄격한 마감 기한에 맞서고 문서화가 완료되지 않을 가능성이 높습니다.

BTW : 개발자는 항상 마감 기한이 지났습니다.

— 개정 JohnFx
소스

12

똑똑한 사람들은 잘못을 잘 할 수 있습니다.

— Jon Hopkins

3

데이터 입력을 완료했지만 확실히 요금을 낮추지는 않았습니다. 그들은 중요한 데이터 입력에 빠르고 정확한 사람을 원했으며 적어도 3 배의 데이터 입력 요금을 지불하는 것을 신경 쓰지 않았습니다. 그들의 선택.

— David Thornley

1

코드를 테스트하는 것이 프로그래머의 일이라고 주장하지만 그것이 당신이 말하는 것이 확실하지 않습니다.

— 벤 레이키

3

프로그래머는 소프트웨어를 파기하는 전문가 인 전담 테스터를 배제하는 것이 아니라 자신의 코드를 테스트해야합니다.

— JohnFx

1

기술 문서 작성에 동의하고 테스트에 동의하지 않습니다. 테스트는 좋은 소프트웨어 작성의 자연스러운 부분입니다. 기술적 인 글쓰기는 코딩에서 너무 많은 변화를 가져옵니다. 코딩에서 테크니컬 라이팅으로 전환하기 위해 많은 장비를 바꿔야한다고 생각하며 시간을 잘 사용하지 못하는 것 같습니다.

— Adam Bruss

63

제품 개발과 관련이없는 연구 / 읽기 / 쓰기 코드는 자원 낭비입니다.

일부 프로그래머와 관리자조차도 그렇게 믿고 있습니다. 일반적으로 그들은 단지 머리에있는 지식을 기반으로 프로그래밍을 수행하고, 문제에 직면했을 때 연구하고 답을 찾습니다. 그들은 지속적으로 지식을 향상시키지 않습니다. 내 의견으로는, 우리는 항상 자신을 최신 상태로 유지해야하며, 수집 한 지식은 기존 및 미래의 문제를 해결하는 데 유용 할 것입니다. 물론 시간을 현명하게 할당해야합니다.

이것은 Dan의 답변 과 비슷합니다 . 일부 관리자는 개발자가 시장의 기존 제품을 연구하지 않고도 요구 사항에 따라 제품을 빠르게 뛰어 들고 개발하기를 원합니다.

— 간
소스

3

나는 이것을 두 번 이상 공표 할 수 있었으면 좋겠다.

— MAK

1

GUI 라이브러리를 작성할 수 있습니다. 메시징 툴킷을 빌드 할 수 있습니다. 소프트웨어를 판매하지 않으면 더 큰 부분 일뿐입니다. 천국에서는 다른 사람의 구현을 사용하기 때문입니다. 오픈 소스 솔루션을 사용하기위한 안전 사항은 필요할 때 언제든지 수정하고 지원할 수 있습니다. 소스가 포함 된 솔루션을 구입할 돈이 있다면 그렇게하지만 상용 소프트웨어 구성 요소의 품질이 좋지 않은 것을주의하십시오. 공급 업체는 구성 요소를 두 번 판매하는 경우가 거의 없으므로, 일단 소유 한 후에 실망 할 수도 있습니다 (이전에 물린 곳에서 일한 적이 있음을 알고 있습니다)

— Tim Williscroft

58

많은 경우에 아웃소싱은 더 많은 비용이 듭니다. 우리 회사에서는 새로운 직원 슬롯을 확보하기가 매우 어려우므로 아웃소싱을 강하게 추진하고 있습니다. 또한 현장 계약자를 얻는 것도 어렵다. 그들이 유지해야하는 해양과 육상의 비율은 3 : 1입니다. 결과적으로, 많은 팀이 단지 12 개의 근해를 고용하고 거의 사용하지 않기 때문에 4 명의 현장 계약자를 얻을 수 있습니다.

— Jeremy
소스

18

+1. 오프쇼어링에 대한 나의 경험은 필연적으로 저축하는 것보다 더 많은 비용이 든다는 것입니다.

— Adam Crossland

2

+1, 그러나 근해가 올바르게 사용될 경우 작동 할 수 있습니다

3

+1. 우리는 각각의 새로운 프로젝트에서 다른 해외 개발자를 얻는 것 같습니다. 즉, 해외 개발자는 기술 지원을 제공 할뿐만 아니라 새로운 해외 개발자에게 비즈니스 및 기술 도메인 모델을 가르치는 데 대부분의 시간을 소비합니다. 프로젝트의 끝과 다른 곳으로 갔고 우리는 다음 '저렴한'개발자부터 다시 시작합니다.

— 크리스 나이트

8

많은 팀이 단지 12 곳의 근해를 고용하고 거의 사용하지 않기 때문에 4 명의 현장 계약자를 얻을 수 있습니다. 와.

— poolie

1

그리고 오프쇼어링은 본질적으로 마감 기한을 연장한다는 것을 잊어 버릴 것입니다. 우리는 해외 QA를 보유하고 있으며, 시간 차이로 인해 같은 사무실에있는 twp 사람들이 1 시간 이내에 재개 할 수있는 것을 다시 사랑하는 데 3-4 일이 소요될 수 있습니다.

— HLGEM

50

긴 피드백 루프!

그것은 모두에게 일어납니다 : 당신은 당신이 굉장하다고 생각하는 것을 만들고, 당신이 틀렸다는 것을 알게됩니다. 그것은 문제가 아닙니다. 문제는 당신이 멈추어야한다는 것을 알기 전에 건물을 얼마나 오래 쓰는지입니다.

높은 수준에서 릴리스주기가 길면이 문제가 발생합니다. 피드백없이 1 년 동안 건축하면 1 년 내내 도박을합니다. 더 자주 출시할수록 도박이 작아지고 도박에 더 좋습니다.

그러나 가장 낮은 수준에서도 발생합니다. 개발자로서 저는 빈번한 코드 검토 (또는 더 나은 페어 프로그래밍)를 좋아합니다. 누군가가 말하기를 "멍청한 방법이 있습니다!" 같은 이유로 단위 테스트가 빠르고 자주 실행되기를 원하므로 버그가 커지기 전에 잡을 수 있습니다.

짧은 피드백 루프의 중요성을 인식하기 시작하면 어디서나 볼 수 있습니다. 예를 들어, OODA 루프 의 군사 개념 .

— 윌리엄 피에 트리
소스

6

+1. 또한 피드백 루프가 길수록 작업에 대한 기억이 줄어 듭니다. 극단적으로, 전체 코드베이스를 다시 한번 알아야합니다.

— Joseph Tanenbaum

어떻게 거짓 경제입니까? 절감 효과는 무엇입니까?

— Chris Pitman

의도는 모든 루프에서 수행하는 작업에 "소비되는"시간을 절약하는 것입니다. 예를 들어, 건물, 테스트, 릴리스, 사용자주의. 어쨌든 변명입니다. 나는 그것이 불편 함을 피하는 데 뿌리를두고 있다고 생각합니다.

— William Pietri 2012

그렇기 때문에 리뷰어와 페어 버디가 코더에 대해 최대한 겸손하고 존중해야합니다. 코더를 잘못 취급하고 귀찮은 피드백 루프가 크게 커질 수 있다는 귀찮은 검토 자.

— Jonathan Neufeld

47

내 일화는 아니지만 개발자에게 무료 커피 제공을 중단 한 상점에 대해 들어 본 적이 있는데, 대신 커피를 마시고 싶을 때 가장 가까운 커피 숍 (10 분 정도)을 자유롭게 걸어 갈 수 있다고합니다. 각 방법으로 여행하고 일부를 구입하십시오.

거짓 경제의 정의와 거의 같습니다.

— 에릭 보어 스마
소스

4

꽤 특별합니다. 출근 시간을 없애기 위해 건물에 보조금을 지급 한 스타 벅스 (Starbucks)를 건설 한 런던의 일부 상인 은행과 비교하고 대조하십시오.

— Jon Hopkins

48

나는 이것이 자동으로 거짓 경제라는 것에 동의하지 않는다.-커피를 사러 나가기 위해 10 분 동안 신선한 공기를 마시면 직원이 산소를 공급하고 집중력이 향상되며 사회적 상호 작용은 (특히 겨울철) 우울증을 줄일 것이다. 커피가 무료가 아니기 때문에 커피를 마시지 않는 직원은 카페인 섭취를 줄임으로써 정시에 집에 돌아와서 더 많은 수면을 취하고 건강을 향상시킬 수 있습니다.

— JBR 윌킨슨

6

-1, 도보로 20 분이면 마음이 편 해지고 문제에 대한 새로운 시각을 얻을 수 있습니다.

— Malfist

23

@Malfist : 내가 이해 한대로, 그것은 단지 20 분 걸음 일뿐만 아니라 15 분도 실제로 작업을 방해 한 커피를 얻기 위해 기다립니다. 하루 중 아무 때나 45 분의 휴식은 1 시간 30 분 이상 생산성을 크게 떨어 뜨릴 것입니다. 커피로 한 달에 100 달러를 절약 할 수 있습니다.

— EricBoersma

8

20 + 15 = 35 [6 자 더]

— Malfist

47

두 번째 모니터가 너무 비싸서 단일 화면 워크 스테이션 제공 . 매년 1 시간의 작업 만 절약하더라도 두 번째 화면은 여전히 좋은 투자입니다. 나는 나의 많은 시간을 절약 할 수 있었음을 확실히 알고있다.

다중 모니터 설정은 개발 작업뿐만 아니라 거의 모든 작업을보다 효율적으로 만들 수 있습니다. 세 대의 모니터가 두 대보다 훨씬 좋지만 매 화면마다 효과가 덜 두드러집니다.

다중 모니터 설정 :

창 전환 오버 헤드 감소
백그라운드에서 실행중인 항목 (메일, 편집 등)을 주시 할 수 있습니다.
당신에게 자유의 느낌을주세요. 마치 아트리움에있는 것과 빗자루 옷장에있는 것과 같습니다.
기타...

— 개정
소스

2

정확히 한 번 그 문제에 직면했습니다. 5 %의 효율성 향상을 감안할 때 내 순이익 대비 약 반달 안에 모니터에 필요한 금액을 절약 할 것이라고 명시 적으로 계산 한 CEO 중 한 명에게 메일을 썼습니다. 이 계산은 꽤 철분했습니다 ... ... ... 당신은 이미 이야기의 끝을 알고 있다고 생각합니다 :)

— 라파엘

39

컨설턴트 비용이 시간당 150 $ 이상인 경우 컨설턴트 에게 제공되는 가장 저렴한 하드웨어 .

더 나은 하드웨어로 생각하면 최소한 하루에 30 분 더 효과적 일 수 있습니다. 그것은 한 달에 30 분 * 20 일의 일 = 600 분 / 월 = 10 시간 / 월> 1 일 이상의 작업 = 10 시간 * 150 $ / 시간 = 1500 $를 줄 것입니다.

1500 달러의 컴퓨터를 가지고 있다면 컨설턴트가 더 효율적이지 않습니까? 컨설턴트가 덜 짜증나게할까요?

이제 문제는 컨설턴트와 PC 하드웨어에 대한 두 가지 예산이있는 것 같습니다.

— 아미르 레자에이
소스

8

컨설턴트로서 저는 그곳에 가서 티셔츠를 받았습니다. (하지만 시간당 $ 80 만 있습니다.)하지만 시간당 계약을 좋아하는 이유 중 하나입니다. 급여를받는 직책과 달리, 컨설팅 고객이 내 시간을 허비하기로 선택하고 보충하기 위해 추가로 일해야하는 경우, 그것은 내 주머니에 더 많은 돈입니다.

— 밥 머피

2

위반은 없지만 컨설턴트에게 시간당 150 달러를 지불하는 경우 자신의 컴퓨터를 사용하는 것이 좋습니다.

— Steven Evers

8

@SnOrfus : 도메인에서 허용되는 PC를 엄격히 제어하는 회사 환경에서는 일반적으로 작동하지 않습니다. 하드웨어를 제공해야합니다.

— HardCode

1

@ HardCode-예, 나는 가정합니다. 요점을 볼 수 있습니다.

— Steven Evers

3

@HardCode 최근 프로젝트에서 우리 (계약자)를 내부 회사 네트워크에 추가하는 대신 우리를 자체 DSL 회선에 격리 시켰습니다. 한 달에 40 달러에 3 명의 개발자를위한 전용 DSL 회선은 변경 사항이며 IT 직원을 공황 상태에 빠뜨리지 않고도 업데이트를 원격으로 쉽게 푸시 할 수 있습니다. 또한 코드를 실행하는 프로덕션 PC가 감염되어 충돌이 발생하면 통신 및 개인 랩톱의 보안을 책임지기 때문에 자동으로 오류가 발생합니다. 당신은 윈윈 윈이라고 말할 수 있습니까?

— Evan Plaice

38

작업 시간은 계획 일을 절약

(계획에 충분한 시간을 투자하지 않음)

— Serg
소스

21

대학원에서는 실험실에서 몇 주 동안 도서관 시간을 절약 할 수 있다는 말이있었습니다.

— David Thornley

7

예. 내가 알려지지 않은 화학 물질을 식별하는 학부 실험실 수업을 들었을 때 교수는 "도서관에서 한 시간은 실험실에서 네 시간을 절약 해 줄 것"이라고 말했습니다. 나는 그를 진지하게 받아 들였고 일주일에 한 시간 동안 실험실로 왈츠를 가져다가 일주일에 12 시간 씩 아민이 아닌 화합물에 대한 아민 테스트를하던 불쾌한 모습을 보는 것이 재미 있었다. 몇 년 후 같은 실험실을 가르쳤을 때 학생들에게 같은 조언을했으며 실제로는 거의받지 못했습니다.

— 밥 머피

3

계획을

27

내가 생각하는 가장 보편적 인 것은 관리자가 단순히 업무를 효율적으로 수행하는 데 필요한 도구를 개발자에게 제공하지 않는 것입니다.

기본적으로 Joel 테스트 에서 9를 가리 킵니다 .

— 부자
소스

2

예를 들어, 이미 수행 한 작업으로 300 달러에 라이브러리를 구매하는 대신 일주일 또는 2 주를 낭비하게 만드는 프로젝트에 참여했습니다. 또는 더 나은 대안이 있는지를 찾는 대신 "이것이나 저것"회사가 만든 소프트웨어 툴을 고르십시오.

— MetalMikester

나는 그 자신을 만났다. PM / 고객 추론은 고객을 위해 물건을 구입할 예산 품목이 없었기 때문에 (연락처 변경은 나쁜) 우리는 바퀴를 다시 발명해야합니다.

— Ken Henderson

24

불행히도 "문제에 몸을 던져 (충분히) 몸통"을 사용하는 경우가 있습니다. Brook 's Law 는 The Mythical Man-Month 에서 이것을 반박 하지만 일부는이 교훈을 배우기 위해 경험이 필요합니다. 경영진이 사람들을 추가하고 그에 대한 대가를 치르지 않을 것이라는 허위 진술을 믿을 수 있기 때문에 일반적으로 이것은 내 힘 안에있는 것이 아닙니다.

— JB 킹
소스

2

+1. 오 그렇습니다 이것은 현재 내가 일하는 주요 프로젝트에서 엄청난 규모로 진행되고 있습니다.

— 바비 테이블

3

나는 프로젝트 리더, 관리자 등 많은 사람들과 함께 일하며 모두 훌륭한 프로젝트 관리 인증을 받았으며 (그것이 무엇이든간에) 어떤 사람도 소개하기 전에 The Mythical Man-Month에 대해 들어 보지 못했습니다. 그것에. esh!

— 밥 자비스

2

한 번에 9 명의 여성이 아기를 낳을 수 없음

— Richard

@Richard 나는 회의에서 그 것을 사용했습니다. 나에게 큰 즐거움을 주었다!

— Tjaart

21

매일 회의 :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...

— 쿨쿨
소스

9

모임을 위해서만 모임을 갖는 것…

— Gan

5

오늘의 의제 : 내일 회의의 의제는 무엇입니까?

— Mark C

9

이것이 짧으면 매일 회의해도 괜찮습니다 . 스크럼 스타일의 3 분 스탠드 업 미팅은 많은 시간을 낭비하지 않지만 모든 사람이 다른 사람의 발전을 인식하도록합니다. 그러나 많은 관심없는 참가자와의 긴 회의는 유독합니다.

— 9000

3

@Mark C-농담처럼 들리 겠지만, 실제로 다음 날 회의의 의제를 계획하기 위해 회의에 초대되었습니다.

— Gavin Coates

@Gavin Coates 그것은 실제 상황입니다 ... :)

— Zzz

20

선반 소프트웨어를 내부적으로 개발하는 대신 구매.

HR 및 생물 실험실에 중점을 둔 기업 규모 관리 시스템에 대한 경험이 있습니다.

기성품 솔루션의 가격은 £ 50-100k이며 비즈니스 요구 사항을 충족시키기 위해 추가 개발 및 사용자 지정이 필요했습니다.

내부적으로 개발 된 솔루션은 개발에 (<6) 개월이 걸렸으며, 다른 프로젝트는 동시에 진행되었으며 이미 고용 된 개발자를 활용했습니다.

나는 내부적으로 개발 한 LIMS (lab information management system)가있는 공공 부문에서 기성품 솔루션의 구현이 1 년 이상 걸리고 아직 완료되지 않은 대형 국제 제약 회사로 갔다.

(6 개월의 이미 고용 된 개발자가 다른 프로젝트를 동시에 작업하고 있습니다. 따라서 ~ 10k이며 이는 기성품 솔루션과 관련된 지원 비용을 포함하지 않습니다). 중요한 점은 내부적으로 개발 된 시스템이 실제로 사용되고 있다는 것입니다! 따라서 계산할 수없는 추가 비용 이점이 있습니다.

기본 웹 사이트 등에 동의합니다. 왜 자신 만의 웹 사이트를 개발해야합니까? 그러나 크고 복잡한 시스템의 경우 이미 사내 기술을 보유하고 있다면 직접 구축 할 것 입니다.

— 개정 NimChimpsky
소스

26

나는 그 반대의 예도 많다고 내기했다.

— Jon Hopkins

13

구매 또는 개발은 실사를하는 올바른 사람들에게 귀속됩니다. 그렇게 간단합니다. 행동하기 전에 생각하십시오. (+1)

— DevSolo

4

@DevSolo : 자리에. 구매 결정은 '여기에 발명되지 않은'감정이나 '나는 XXX의 소프트웨어를 좋아한다'라는 태도보다는 비용-이익 분석에 의해 뒷받침되어야합니다.

— JBR 윌킨슨

9

빌드 대 구매에 대해 포괄적으로 설명하려는 경우 회사의 핵심 역량에 속하지 않는 문제에 대한 솔루션을 구매하는 것을 선호합니다. 항상 정답은 아니지만 합리적인 기본 위치이며 진부한만큼 신뢰할 수 있습니다. 그러나 기성품 소프트웨어를 구입하는 것은 잘못된 경제라고 말하면 유용한 진부한 표현조차 아닙니다 .'E '솔루션 ('엔터프라이즈 '를 의미하는 것으로 생각되지만 실제로는'비용이 많이 드는 '솔루션)에 대한 고통을 느낍니다. '). 그러나 나쁜 옵션이 있다고해서 좋은 옵션이 없다는 것을 의미하지는 않습니다.

— evadeflow

2

문제는 구매 한 다음 추가 개발 및 사용자 정의가 여전히 필요 하다고 생각합니다 . 대형 시스템에서 약간의 사용자 정의 비용은 종종 원하는대로하는 작은 시스템을 작성하는 것보다 많을 수 있습니다. 따라서 구매하는 시스템이 작동 할 것으로 예상되는 방식으로 작업 할 수 있다면 구매하십시오. 그러나 구매 및 사용자 정의는 양쪽 모두를 악화시킬 수 있습니다!

— Ian

15

오픈 소스 대안이 더 좋고 무료 일 때 값 비싼 상용 제품을 구매합니다.

자식을 사용하는 회사는 몇 개입니까? 몇 개의 회사에서 엉뚱한 엔터프라이즈 버전 관리를 사용합니까?

— Hasen
소스

1

음, 이것이 "가장 최악의 거짓 경제"로 간주 될 수 있습니까? 아니면 더 자세히 설명해야할까요?

— Gan

3

최소한 소스 제어의 예에 완전히 동의하지는 않습니다. Git은 오픈 소스 문제를 해결하기 위해 특별히 설계되었습니다. 많은 개발자, 작은 중앙 제어, 많은 지점 등. "엔터프라이즈"소프트웨어는 다음과 같은 다양한 가정 하에서 작동합니다. 비즈니스, 보안, 워크 플로 등

— PeterAllenWebb

1

@Gan : 오픈 소스를 사용하는 것은 잘못된 경제라고 생각하지만 모두 거꾸로 가지고 있습니다.

— 하센

3

저는 X11과 GNOME에 기고자이며 git 사용 및 gitosis 서버 관리에 상당히 능숙합니다. 그럼에도 불구하고 이번 여름에는 컨설팅 작업을 git에서 개인 지불 유료 Perforce 서버로 전환했습니다. git으로 수동으로 해야하는 많은 작업을 자동으로 수행하기 때문입니다. 코드를 제공하고 비용을 지불하지 않고 버전 제어를하지 않기 때문에 "크 래피 엔터프라이즈 버전 제어"를 사용하고 지불하는 것이 git을 사용하는 것보다 훨씬 비용 효율적입니다.

— 밥 머피

7

오픈 소스와 상용 제품은 실제로 제 경험상 "사례 별"기준입니다.

— MetalMikester

14

표현력이없는 "간단한"언어 사용

예, 코드를 유지할 프로그래머를 찾는 것이 더 쉬워 지지만, 채용 할 최신 유행어를 배우지 않는 훌륭한 프로그래머 를 찾기가 더 어려워집니다 . 예, 개별 비트 코드를 이해하기 쉽게 만들지 만 2x4만큼 견고하게 만들고 이해해야 할 코드의 양을 늘립니다. 예, 대기업의 지원을 받고 있지만 대기업은 느리고 관료적으로 혁신하고 있습니다.

— 딤차
소스

4

@ burnt_hand : 기본적으로 언어 선택 측면에서 경영진의 과도한 위험 회피를 말합니다.

— dsimcha

1

+1 : "우리는 그러한 기술을 보유하고 있으며 Python / Perl / PHP와 같은 새로운 멋진 언어를 배우면 큰 위험에 빠지기 때문에"C를 계속 사용하십시오. 한 번 이상 들었습니다. 그것은 팀이 새로운 언어를 배우기에는 너무 어리 석다는 것을 의미합니까?

— S.Lott

1

@ S.Lott 모집 에이전트는 당신이 생각합니다! 그러나 그것은 또 다른 이야기입니다

— burnt_hand

2

: 자바와 C #을 고수하고 그들이 생각 나게 "업계 표준"아니에요 때문에 파이썬이나 루비를 만지지 너무 두려워 즉 회사 paulgraham.com/avg.html

— 하센

1

@hansen : Paul Graham 에세이는이 글을 쓰는 데 영감을 준 부분입니다. 다른 영감은 D 프로그래밍 언어를위한 라이브러리 (표준 라이브러리 포함)를 개발하는 작업이었습니다.

— dsimcha

13

프로젝트 관리자 / 팀장이 잘못되었습니다.

한 무능한 사람은 한 무리의 사람들의 일을 망칠 힘이 있기 때문에. 결국, 프로젝트는 고위 경영진 (프로젝트 / 팀장)의 결정없이 훨씬 더 나을 것입니다.

"그냥 빨리 해, 나중에 리팩토링 할 것"이 결정됩니다.

— Amir Rezaei
소스

4

나는 관리자가 나쁜 데 동의하지만 "프로젝트가 상위 경영진의 결정없이 훨씬 나아질 것"이라고 생각합니다. 일반적으로 이들은 프로젝트를 후원하는 사람들입니다. 이것은 내가 비즈니스를 이해하는 것보다 기술을 이해하는 것이 더 중요하다고 생각하고 실제 고객이 누구인지를 잊어 버린 개발자와 조금 비슷합니다.

— Jon Hopkins

2

@Jon Hopkins 최고 경영진은 고객을 언급하지 않습니다. 요점은 "나쁜 프로젝트 관리자"는 실수 후 실수를 저지르고 사람들의 그룹에 대항하는 사람들입니다. 누가 "그냥 빨리하면 나중에 리팩터링 할 것"이라고 누가 생각 하는가? 가장 높은 비율로 답을 읽으십시오!

— Amir Rezaei

아, 더 깨끗해. 내 -1을 제거합니다.

— 존 홉킨스

품질과 시간과 비용을 수정하는 프로젝트 관리자들의 혼란스러운 경향을 발견했습니다. 내가 유일한 사람은 아니라고 확신합니다. PM은 삼각형 다이어그램을 비용 / 품질 / 시간과 함께 사용하는 것을 좋아하지만 품질은 항상 먼저 부팅됩니다. 매우 슬프고 소프트웨어처럼 복잡한 것에 대한 프로젝트 관리 (PMI) 지표를 제도화하고 강요하는 것은 상황을 악화시키는 것 같습니다.

— Bernard Dy

1

@Bernard-시간과 비용을 측정 할 수 있습니다. 품질? 별로. 슬프지만 IMO는 사실 ...

— 밥 자비스

12

누락 된 사용자 요구 사항

소프트웨어 제품을 설계하는 중요하고 어려운 단계는 고객이 실제로 원하는 것을 결정하는 것입니다.

믿거 나 말거나 때때로이 부분이 없거나 오래되었습니다. 비용은 최종 사용자가 요청하지 않은 기능을 생성한다는 것입니다.

— Amir Rezaei
소스

나는 이것이 정상에 있어야한다고 생각합니다!

— Roopesh Shenoy 11

8

생산성은 창의성보다 가치가 있습니다

창의성은 일반적으로 측정하기가 어렵고 소프트웨어 개발과 관련하여 측정하지 않아도됩니다. 한편, 생산성은 측정 될 수 있고 (종종 열악한) 관찰 될 수있다.

결과적으로 (질문에 대한 답변으로 더 많은 코드 줄을 더 빨리 작성 | 더 빨리 기술 코드를 더 빨리 작성할 수 있음 | 더 눈에 띄게 생산적임) 개발자는 (같은 문제를 해결하기 위해 더 적은 코드 줄을 사용함) 코드를 작성하는 데 시간이 오래 걸리지 만, 질문을 명확하고 이해하기 쉽고 영어로 창의적으로 해결하기에 충분할 정도로 주제를 더 잘 이해할 수 있습니다.

— 블루 베리 필드
소스

6

아래를 모두 사용하거나 부적절하게 사용하지 않으면 나쁠 수 있습니다

외부 소프트웨어와 사내 소프트웨어
ISO 9001 준수 (경제-제품 품질 저하시 MSS 손실 위험 완화)
개발 / QA 아웃소싱
개발 / 빌드 / 릴리스 / 지원 절차

— 보바
소스

ISO 9001은 어떻게 "경제"입니까?

— Andrew Grimm

@Andrew Grimm-규정 준수는 특정 품질 수준을 보장하여 품질 저하 (예 : MSS 손실)로 인한 위험을 완화시켜 잠재적 인 경제를 명확하게합니다. 소규모 부서의 경우 오버 헤드 손실이 잠재적 위험의 손실보다 높기 때문에 부적절 할 수 있습니다.

— bobah

1

@Andrew-내 경험상 그것은 당신이 원하는 것에 달려 있습니다. 품질을 높이려면 비용이 많이 들고 소프트웨어에 적합하지 않을 수 있으므로 잘못된 경제 일 수 있습니다. 당신이 그것을 마케팅 일로 원하거나 그것이 당신의 산업에서 기대되기 때문에, 그것은 잠재적으로 좋은 생각입니다.

— Jon Hopkins

5

@Andrew Grimm-ISO 9001이 보장하는 "유일한"것은 일관되고 반복 가능한 품질입니다. "높은"품질을 보장하지는 않습니다. 그러나 ISO 9001 인증이 회사가 원하는 시장 공간에 필요한 것이라면 요구됩니다.

— Vatine

1

@Vatine : ISO 9001이 보장하는 것은 일관되고 반복 가능한 프로세스입니다. 일관된 프로세스가 일관된 품질을 제공하는 일부 분야에서는 이것이 중요합니다. 고품질을 보장하지는 않지만 고객이 자신이 잘 한 일을보고 ISO 9001 인증을 받았다는 것을 알게되면 비슷한 품질을 확신하게됩니다.

— David Thornley

4

청구 불가능한 배송 관리자가 너무 많습니다.

몇 년 전, 우리 회사에서는 몇 가지 큰 예산 프로젝트가 진행되었으며 채용은 절정에 달했습니다. 당시 우리 회사는 너무 많은 배달 관리자 (많은 사람들이 IT가 아니 었습니다!)를 고용했으며 코더 / 테스터는 거의 없었습니다. 관리자 대 프로그래머 비율은 문자 그대로 1 : 2입니다. 나중에 그 프로젝트를 완료 한 후, 우리는이 관리자들 중 일부 (실제로 슬랙 커)가 아무 것도하지 않고 벤치에 앉아있는 상황에 처했습니다. 우리는 모두가 거의 또는 전혀 모금을받지 못한 (한 번도 열심히 일하는 프로그래머라도 한숨을 쉬는) 평가주기를 가졌으므로 회사는 다른 사람을 해고 할 필요가 없습니다! 다행히도 회사는 이러한 상황을 인식하고 올해 1 분기에 RIGHTSIZING을 수행했습니다!

— 마난 자니
소스

3

프로파일 링 전 최적화 (일명 조기 최적화).

너무 많은 시간에 누군가가 더 빠른 근거로 유지 관리 및 가독성을 불필요하게 복잡하게 만드는 영리한 솔루션을 찾는 것을 보았습니다. 당연히이 코드는 벤치 마크가되지 않았으며 (마이크로 벤치 마크조차도 아님) 전체 코드의 전반적인 성능에 영향을 미치지 않을 가능성이있는 코드 섹션에 대해 "더 설득력있는 주장에 근거하여"더 빨리 빨라집니다 많은 응용 프로그램.

따라서, 그것은 매우 거짓 경제이며, 노련한 전문가조차 가끔 얽매는 일종의 거짓 경제입니다.

— 에드윈 벅
소스

3

인터넷 액세스 제한

직원들이 인터넷을 사용하여 페이 스북 게임을 즐기기 때문에 Stackoverflow의 기술적 질문에 대한 답변을 연구하지는 않습니다.

실제로 인터넷은 생산성을 크게 향상 시키며 진정으로 피하기 쉬운 사이트에 일종의 사이트 필터를 사용하는 것이 적절할 수 있지만, 이유 때문에 Visual Studio 추가 정보 파일을 차단하거나 텔 포드 지역 정부 페이지를 차단하는 경우 문제가 있습니다 "성 관광"

— jk.
소스

2

개발자가 회사 표준 인 15 인치 모니터 및 저사양 PC를 사용하도록합니다.

합리적인 크기의 모니터는 저렴하고 설치가 빠르며 프로그래머의 생산성을 높이고 프로그래머가 관심을 갖도록합니다.

— 이안
소스

2

"KPI", "SLA"를 가진 사람들을 귀찮게하고 "보고서"를 요구하지 않는 사람들을 귀찮게하는 것 물론 프로그래머가 멋진 EXCEL 시트, Q4 보고서 및 하나의 위대한 새로운 관리 도구에서 복사하여 다른 도구로 복사하여 붙여 넣는 일을 낭비하지 않도록하십시오 (이것은 규칙 인 것 같습니다. 이러한 도구는 서로를 설명하거나 통합 할 수 없으며 보고서와 그림이 제시된 회의에 참석합니다 (그리고 모든 사람이 KPI를 완전히 처리하지 못한 것에 대해 죄책감을 느끼게됩니다).

— 잉고
소스