Kio estas la sindromo "Ne inventita ĉi tie"?
Inĝeniera kulturo kaj programara praktiko
La sindromo "Ne inventita ĉi tie" estas la kutimo malfidi aŭ malakcepti ideojn, ilojn aŭ kodon ĉefe pro tio, ke ili venis de ekster la teamo aŭ organizo. En programaro, ĝi manifestiĝas kiam inĝenieroj rekonstruas aferojn kiuj jam ekzistas, kontraŭstaras komunajn normojn, aŭ supozas ke interna laboro estas aŭtomate pli bona. Foje tiu instinkto kaŝas fierecon aŭ tribismon. Foje ĝi reflektas verajn zorgojn pri kontrolo, licencado, sekureco aŭ prizorgado. La malfacila parto estas distingi unu de la alia.
Reviziita de Jackie, Estro de Lernado kaj Disvolviĝo, Levellers - Laste reviziita la 8-an de junio 2026
Kion tio signifas
Ĉiu inĝeniera teamo devas decidi, kion krei mem kaj kion adopti de aliloke. Tio povas signifi aĉeti produkton, uzi malfermkodajn bibliotekon, dividi internan platformon, aŭ akcepti normon konstruitan de alia teamo. La sindromo "Ne inventita ĉi tie" aperas kiam tiu elekto jam estas emociece farita antaŭ ol la pruvoj estas ekzamenitaj.
La frazo estas kutime uzata kiel kritiko, sed ĝi ne estas tiel simpla kiel "konstrui mem estas malbona". Teamoj foje havas bonajn kialojn eviti eksterajn dependecojn. Ili eble bezonas pli profundan kontrolon, pli bonan sekurecan revizion, pli striktan rendimenton, aŭ pli fortan produktan distingon. La sindromo estas la antaŭjuĝo, ne la simpla ago de konstruado.
Kial ĝi gravas
Tiu ĉi aspekto de inĝeniera kulturo gravas ĉar ĝi troviĝas ĝuste en la mezo de kosto, rapido kaj proprieto. Teamo kun fortaj NIH-instinktoj povas pasigi monatojn rekonstruante infrastrukturon kiu aldonas malmultan avantaĝon. Teamo sen ia ajn skeptikismo povas importi fragile dependecojn, krei vendist-ligitecon, aŭ transdoni strategian kapablon al iu alia. La elekto malofte estas nur teknika. Ĝi estas samtempe kultura, politika kaj ekonomia.
Ĝi ankaŭ gravas por ĉiu kiu laboras flanke de inĝenieroj. Produktaj gvidantoj kaj direktoroj ofte aŭdas "ni devus konstrui tion mem" kaj supozas, ke tio estas klara teknika konkludo. Foje ĝi estas. Foje ĝi estas identeca deklaro en kamuflado. Koni la terminon helpas vin demandi pli bonajn demandojn antaŭ ol prefero fariĝas plurkvartala engaĝiĝo.
Kiel ĝi funkcias
De kie venas la termino
La frazo originis el esplorado kaj administra diskuto pri esplor-kaj-disvolv-grupoj kiuj iom post iom fariĝis enrigardaj. En teknologio, ĝi restis ĉar la ŝablono estas facile rekonebla. Teamo traktas eksteran laboron kiel suspektindan defaŭlte kaj internan laboron kiel fidinda defaŭlte, eĉ kiam la pruvoj montras la kontraŭon.
Tiu defaŭlto povas esti subtila. Neniu anoncas: "ni malakceptas eksterajn ideojn". Anstataŭe homoj diras: "ni bezonas ion pli adaptitan", "tiu biblioteko ne estas produkta-nivela", aŭ "ni povas rapide fari pli bonan version en unu sprint". Foje tiuj juĝoj estas ĝustaj. NIH estas tio, kio okazas kiam ili fariĝas kutimaj kaj memflatemaj.
Kial inĝenieroj estas inkliniĝemaj al ĝi
Parte la respondo estas kontrolo. La kodo de aliaj venas kun nekonataj supozoj, eldonhoroj, cimaj prioritatoj, nomaj elektoj kaj subtenmodeloj. Legi ĝin estas pli malrapida ol skribi freŝan kodon. Adapti ĝin povas sentiĝi kiel kompromiso. Tiu malkomforto estas reala, kaj ĝi ofte puŝas teamojn al rekonstruado.
Parte ĝi estas fiereco. Programaro estas metiarto, kaj inĝenieroj tre kompreneble zorgas pri kvalito. Se teamo estis vundita de malbone vendisto aŭ malordigita komuna platformo, "ni devus posedi tion mem" povas sentiĝi kiel kompetenteco anstataŭ egoo. La problemo estas ke kompetenteco kaj posedemo povas soni identaj en fruaj kunvenoj.
Ekzistas ankaŭ loka instigproblemo. Konstrui novajn aferojn estas videbla kaj prestiĝa. Integri la laboron de iu alia, plibonigi suprenfluan dokumentadon, aŭ fortikigi komunan internan bibliotekon estas malpli glamura. Multaj organizoj celebras inventadon pli ol zorgan adopton. Surbaze de tiuj instigoj, NIH povas aspekti kiel iniciato.
Kiam la instinkto estas prudenta
Ĉi tie la termino bezonas zorgecon. Malakcepti eksteran komponenton ne estas aŭtomate neracia. Ĝi povas esti saĝa se la kapablo estas centra al via produkto, se juraj aŭ sekurecaj limigoj estas severaj, se la suprenflua projekto estas forlasita, aŭ se la dependeco kreus longan ĉenon de subtenaj kapdoloroj. Joel Spolsky faris la utilan kontraŭargumenton antaŭ jaroj, ke reuzado povas krei malagrablan interdependecon. Komuna kodo ne estas senkosta nur ĉar vi ne tajpis ĝin.
Sana teamo do demandas du malsamajn demandojn. Unue: ĉu la ekstera afero estas sufiĉe bona por nia reala bezono? Due: kion vere kostas posedi la aferon mem laŭlonge? La NIH-sindromo ekiĝas kiam la unua demando estas forĵetita kaj la dua estas fantaziita for.
La plej bona kontraŭkulturo eble estas la frazo "fiere trovita aliloke". Ĝi kaptas maturan inĝeniran sintenon. Uzu tion, kio jam funkcias, kiam ĝi vere konvenas. Konstruu kie proprieto estas strategie inda je la longdaŭra ŝarĝo. Ne konfuzu novaĵon kun avantaĝo.
Ekzemploj
Kompanio jam havas komunan aŭtentikigan platformon uzatan de pluraj produktoj. Nova teamo decidas skribi sian propran ĉar la komuna platformteamo estas "tro malrapida". Dek ok monatojn poste ili prizorgas ensalutflujojn, pasvortrestarigojn, revizioregistrojn kaj konformecajn laborojn kiuj neniam estis parto de la distinga valoro de ilia produkto.
Malantaŭa teamo rifuzas uzi maturan malfermkodajn atendovicbibliotekon ĉar ili estas certaj, ke ili povas produkti pli maldikan internan version. Ili povas, komence. Poste mesaĝa ordigado, reprovaĵoj, observebleco, ĝisdatigoj kaj dokumentado alvenas kiel neinvititaj parencoj. La atendovico fariĝas flanka negoco.
Organizo kreas kvar iomete malsamajn internajn dezajnsistemojn ĉar ĉiu produktgrupo volas aŭtonomion. Ĉiu sistemo estas racia en si mem. Kune ili kreas duobligitan alireblecajn laboron, duobligitajn komponentajn cimojn kaj duobligitan enkondukan doloron.
Oftaj miskomprenoj
La sindromo "Ne inventita ĉi tie" ne signifas, ke ĉiu interna konstruaĵo estas vanteco. Foje konstrui estas ĝuste ĝusta, precipe por kapablo kiu difinas la produkton aŭ portas nekutimajn limigojn.
Ĝi ankaŭ ne estas kuracebla per krio "konstrui kontraŭ aĉeti" kaj deklaro de la pli malmultekosta nombro kiel venkinto. Adopto havas integrigajn kostojn, administrajn kostojn kaj eskapajn kostojn. Konstruado havas prizorgajn kostojn, dungajn kostojn kaj randkazajn kostojn. La komparo bezonas ambaŭ flankojn.
Alia miskompreno estas ke NIH estas nur administra problemo. Ĝi povas loĝi ie ajn. Individuaj inĝenieroj faras ĝin, teamoj faras ĝin, kaj direktoroj faras ĝin. La direktora versio ofte estas aĉeti brilantan eksteran platformon ĉar interna laboro sentiĝas malnova kaj senentuziasmiga.
Fine, la kontraŭa ekstremo ne estas saĝo. Blinde importi ĉiun dependecon, servon aŭ akiritan ilon ĉar iu alia jam faris ĝin estas malsama speco de malbona juĝo, kaj ĝi ofte finiĝas en dependeca infero.
Riskoj kaj limoj
La frazo povas fariĝi konversacia haltigilo. Se ĉiu zorgema obĵeto kontraŭ ekstera dependeco estas etikedita NIH, teamoj perdas la kapablon diskuti verajn problemojn kiel datuma loĝloko, sekureca revizio, opereblo, lerteckongrueco, aŭ totala posedkosto. Nomi iun NIH neniam devus ŝpari al vi la laboron de prezenti la argumenton.
Ekzistas ankaŭ homa limo. Foje tio, kio aspektas kiel NIH, estas timo. Teamoj konas sian propran stakon, sian propran alarmoŝarĝon kaj siajn proprajn limdatojn. Ili eble kontraŭstaras eksteran kodon ĉar ili ne fidas, ke la organizo subtenos ilin kiam integriĝo malfaciliĝas. En tiu kazo la vera problemo ne estas aroganteco. Ĝi estas la manko de komuna fido.
Kion fari poste
Komencu per tio, ke konstrui, adopti, forki kaj aĉeti fariĝu eksplicitaj opcioj anstataŭ tribaj identecoj. Petu ĉiun teamon skribi, kial kapablo estas inda je proprieto, kian ŝarĝon tiu proprieto alportas, kaj kio devus esti vera por ke ekstera alternativo estu akceptebla.
Rekompenci integrigajn kaj administrajn laborojn. Se antaŭenigoj kaj laŭdoj sekvas nur verdajn konstruaĵojn, homoj daŭre rekonstruos. Teamoj devus ricevi krediton por redukti duobligadon, kontribui korektojn suprenflue, plibonigi komunajn platformojn kaj forigi nenecesajn lokajn kopiojn.
Helpas ankaŭ difini, kio estas vere strategia. Kompanio ne bezonas laŭmendajn ĉion. Ĝi bezonas klarajn kialojn por la malmultaj aferoj, kiujn ĝi vere volas profunde kontroli. Kiam tiu linio estas videbla, multaj NIH-debatoj fariĝas malpli emociaj kaj pli honestaj.
Ĉu vi havas demandon aŭ sugeston, aŭ volas kompreni kiel ni esploras kaj reviziis tiujn gvidilojn? Legu pri niaj redakciaj normoj kaj kiel kontakti nin.
Oftaj demandoj
Ĉu la sindromo "Ne inventita ĉi tie" estas la sama kiel konstrui kontraŭ aĉeti?
Ne. Konstrui kontraŭ aĉeti estas la decido. NIH estas la antaŭjuĝo kiu povas distordis tiun decidon antaŭ ol pruvoj estas ĝuste pesitaj.
Ĉu malfermkoda programaro povas redukti NIH?
Ofte jes. Malfermkoda programaro povas faciligi inspektadon, testadon kaj plibonigon de ekstera kodo. Sed ĝi ne forigas prizorgajn, ĝisdatigajn aŭ administrajn zorgojn.
Kio estas la kontraŭo de NIH?
Homoj foje diras "fiere trovita aliloke". La malsana kontraŭo estas importi aferojn senkritike nur ĉar ili estas modaj aŭ eksteraj.
Ĉu NIH estas ĉiam neracia?
Ne. Eksteraj iloj kaj kodo vere alportas dependecajn, subtenajn kaj ligitecajn kostojn. La problemo estas malakcepti ilin per reflekso anstataŭ per zorgema juĝo.
Kiel teamo povas scii, ĉu ĝi estas justa?
Petu skriban komparon de adoptkosto, posedkosto, risko kaj strategia graveco. Se la argumento dependas ĉefe de gusto aŭ fiereco, NIH eble estas en ludo.
Ĉu NIH okazas nur kun eksteraj vendistoj?
Ne. Ĝi ofte okazas ene de grandaj kompanioj, kiam unu produktteamo malakceptas internajn platformojn aŭ ignoras kodon konstruitan de alia grupo.
Fontoj
Documentation/CodingStyle and Beyond (Ottawa Linux Symposium). A grounded engineering example that explicitly tells kernel contributors to reuse well designed, well debugged facilities rather than reinventing them.