У одбрану синдрома „није измишљено овде“
From The Joel on Software Translation Project
Време је за штих пробу.
1. Рециклажа кода је:
а) Добра б) Лоша
2. Измишљање топле воде је:
а) Добро б) Лоше
3. Синдром „није измишљено овде“ је:
а) Добар б) Лош
Наравно, опште је познато да увек треба да се искористи туђи код. Исправни одговори су наравно, 1(а), 2(б), 3(б).
Јел' тако?
Где журите!
Синдром „није измишљено овде“ спада у класичну патологију управљања, где тим одбија да користи технологију коју нису сами направили. Људи са НИО синдромом су очигледно синтичави, и одбијају да раде у најбољем интересу целокупне организације јер не могу да нађу начин да преузму заслуге. (Јел' тако?) Одељак „досадне историје пословања“ у локалној суперкњижари врца од прича о глупим тимовима који су потрошили милионе долара и дванаест година правећи нешто што су могли да набаве код Проке Проналазача за 9.99 долара.
Било ко, ко је пратио са имало пажње три деценије напретка у програмирању рачунара зна да је рециклажа Свети грал свих савремених програмских система.
Дабоме. Па, то сам и ја исто мислио. Једном сам тако био управник програма задужен за прву имплементацију Вижуал бејзика за апликације (Visual Basic for Applications), саставио сам пробрану коалицију четири, пазите, четири различита тима у Микрософту (Microsoft) да бисмо добили наменске дијалоге у Екселовом ВБА (Excel VBA). Идеја је била сложена и проткана међузависностима. Постојао је тим А-Еф-Икс (AFX) који је радио на некој врсти едитора за дијалоге. Онда бисмо ми користили овај ганц нови код од групе за ОЛЕ (OLE) који је допуштао да се једна апликација угради у другу. А тим Вижуал бејзика би обезбеђивао програмски језик иза њега. Након једне седмице преговора, успео сам да наведем тимове А-Еф-Икс, ОЛЕ и ВБ да се с тиме сложе у принцпу.
Навратио сам до канцеларије Ендруа Кватинеца (Andrew Kwatinetz). Он је био мој управник у то време и научио ме је свему што знам. „Развојни тим Ексела то никада неће прихватити,“ рекао је. „Знаш ли њихов мото? Пронађи међузависности -- и елиминиши их. Никада неће пристати на нешто са толико међузависности.“
За-ним-љи-во. Нисам то знао. Претпостављам да то објашњава зашто је Ексел имао сопствени Це (C) компајлер.
Довде се моји читаоци сигурно ваљају по поду од смеха. „Зар није Микрософт глуп“, мислите, „одбијају да користе туђи код и чак имају сопствени компајлер само за један производ.“
Где си кренуо, буразеру! Тврдоглави менталитет независности Екселовог тима такође је значио да су увек испоручивали на време, да је код био уједначено висококвалитетан и имали су компајлер који је осамдесетих генерисао п-код (pcode) и према томе радио без измена на Мекинтошевом (Macintosh) чипу 68000 као и на Интеловом ПЦју. П-код је чинио извршне датотеке упола мањим од величине коју би имале Интелове бинарне датотеке, и учитавале су се брже са флопи дискова и тражиле мање РАМа.
„Пронађи зависности -- и елиминиши их“. Када радите у веома, веома добром тиму са сјајним програмерима, било чији туђи код је, искрено говорећи, ђубре заражено баговима, и нико други не зна како се испоручује на време. Када сте кувар са плавом траком и када вам треба свежа лаванда, онда је гајите сами а не купујете је на пијаци, где некада немају свежу лаванду или имају бајату коју потурају као свежу.
Заиста, током скорашње дот-ком маније, гомила луцкастих писаца сугерисала је да ће компанија будућности бити потпуно виртуална -- само тренди пар који пијуцка Шардоне у дневној соби и све аутсорсује. Ови захуктали „визионари“ су превидели да тржиште плаћа додату вредност. Двоје јапија у дневној соби који купују енџин за е-комерц од компаније А и продају робу коју продаје компанија Б а складишти је и шаље компанија Ц, са корисничком подршком од компаније Д, руку на срце не додаје много вредности. Заправо, ако сте икада морали да аутсорсујете критичну пословну функцију, онда знате да је аутсорсинг пакао. Без директне контроле над корисничком подршком, имаћете кошмарно лошу корисничку подршку -- онакву о каквој људи пишу на својим веблоговима када покушају да им неко, било ко, из неке телефонске куће уради макар и најосновнију ствар. Ако аутсорсујете добавку, а ваш партнер за добавку има другу идеју како изгледа промптно испоручивање, ваше муштерије неће бити задовољне, и нећете моћи ништа да урадите против тога, јер вам је требало три месеца само да нађете партнера за добавку и, у ствари, нећете ни знати да су вам муштерије незадовољне, пошто не могу да причају с вама, пошто сте поставили аутсорсовану корисничку подршку са јасним циљем да не слушате сопствене муштерије. Тај енџин за е-комерц ког сте купили? Нема шансе да је тако флексибилан као Амазонов обидос кога су сами написали. (А ако јесте, онда Амазон нема предност над конкурентима који су купили исту ствар) И ниједан веб сервер из радње неће бити тако блиставо брз као што је Гуглов ручно писани, ручно оптимизовани сервер.
На жалост, овај принцип је изгледа у директном сукобу са идеалом „рециклажа кода добра -- измишљање топле воде лоше.“
Најбољи савет ког могу да дам:
Ако је у питању главна пословна функција -- радите је сами, без обзира на све.
Изаберите главне способности и циљеве, и то радите код куће. Ако сте софтверска фирма, писање одличног кода је начин да успете. Само напред, аутсорсујте компанијску мензу и копирање компакт дискова. Ако сте фармацеутска фирма, пишите програме за истраживање лекова, али не пишите свој програм за књиговодство. Ако сте фирма за мрежно књиговодство, пишите сопствени пакет за књиговодство, али немојте сами да правите огласе у новинама. Ако имате муштерије, никада не аутсорсујте корисничку подршку.
Ако развијате рачунарску игру где је заплет ваша предност над конкуренцијом, у реду је да користите 3Д библиотеку од трећег лица. Али ако ће кул 3Д ефекти бити знак распознавања, боље би било да направите своје.
Једини изузетак од овог правила, претпостављам, је ако су ваши људо неспособнији од свих других, па кад год пробате да нешто урадите код куће, то пропадне. Јесте, постоји много таквих места. Ако сте на једном од њих, не могу да вам помогнем.
