Joel a Szoftverről – gerilla magyar fordítások

Funkcionális specifikációk egyszerűen – Funkcionális specifikáció írásáról szóló cikksorozat. „Szoftvermérnökök, akik specifikáció nékül vágtak kód írásába, azt gondolják, hogy úgy is remek programozók, csípőből lőnek. De nem. Valami szörnyen terméketlenek. Rossz kódot írnak, gyenge minőségű terméket készítenek. Ez óriási kockázattal fenyeget, ami teljességgel indokolatlan”.

Építsünk csapatot! – hogyan építsünk fel egy remek fejlesztőcsapatot?

Ne felejtsd el azt a fontos dolgot interjúztatáskor, hogy sokkal jobb nemet mondani egy jó jelentkezőre, minthogy igent mondanál egy rossznak. Egy rossz jelentkező sok pénzedbe, erőfeszítésedbe fog kerülni, nem beszélve a kollégái többletmunkájáról, amit a rossz munka után kell végezniük. Szóval ha bármilyen kétséged felmerül, ne vedd fel. Az interjúztatás gerilla-taktikája

A Joel-teszt – elkészítettem a saját, meglehetősen megbízhatatlan, hanyag tesztemet, ezzel könnyedén felmérhetem szoftverfejlesztő csapatok minőségét. Az az előnye, hogy csak három perc az egész. A megspórolt idő alatt elvégezheted az orvosi egyetemet.

Miért nem készít senki sem ütemtervet? Ennek két fő oka van: az egyik a gyötrelem. A másik az, hogy senki sem hiszi, hogy az egész ér valamit. Miért is fárasszam magam ütemterv készítésével, ha úgysem lehet betartani? Van egy egyszerű, fájdalommentes módszer, amellyel olyan ütemtervet készíthetünk, ami tulajdonképpen használható.
Szoftverfejlesztőként hibát javítani jó. Igazam van? Nem igaz? Nem! A hibajavítás csak akkor fontos, ha a hibajavítás értéke túlszárnyalja a hibajavítás költségeit. Keménytökű hibajavítás.
Ez a weboldal elvileg szoftver-fejlesztések irányításáról szól. Esetenként azonban nincs meg a hatalmad, hogy vezetői rendelkezésekkel változtass a rendszeren. Amíg csak egy mezei programozó vagy a ranglétra alján, nyilvánvalóan nem tudsz csak úgy utasítani másokat, hogy kezdjenek el ütemtervet írni vagy hibakövető rendszert használni. Még ha vezető vagy, akkor is már valószínűleg észrevetted, hogy fejlesztőket irányítani körülbelül annyira lehet, mint macskákat terelni, csak kevésbé szórakozató. Attól, hogy azt mondod, „csináld így”, még nem lesz úgy.

Egy menedzsmentfilozófia – vezesd a csapatod Joel módszere szerint

Képzeljük el, hogy a céged célja nem valamiféle speciális probléma megoldása, hanem hogy a pénzt programozók által kódra változtassa.
Csupán a móka kedvéért: hasonlítsunk össze egy szabálysereget pontosan követő, az ételekről nem sok elképzeléssel bíró McDonald's-munkást, és a Pucér Szakács név alatt tevékenykedő jóképű brit zsenit, Jamie Olivert! (Ha e ponton a tisztelt olvasót erős késztetést érez, hogy a linket követve inkább A pucér szakács bazsalikomos ajóka-saláta (és más hasonlók) készítését taglaló, MTV-szerűen megkomponált klippjeiben gyönyörködjön, akkor áldásom rá. Egészségére!) A Big Mac és a Pucér Szakács.
Egy teljes sebességgel kódot író programozó kismillió dolgot tart egyszerre fejben: változóneveket, adatstruktúrákat, fontosabb API-kat, saját készítésű és gyakran használt segédfüggvények neveit, még a forráskódot tartalmazó alkönyvtár nevét is. Ha most ez a programozó három hétre Krétára megy nyaralni, akkor mindezt elfelejti. Miért ritkítsuk meg az emberi feladatváltásokat?

A műszaki igazgató kiskátéja – amit a felső műszaki vezetőknek tudniuk kell

Rendszertervezéskor a használt eszközöket is el kell dönteni. Jó tervező pedig csak megbízható vagy megjavítható eszközökre támaszkodik. Egyébként nyakig fog ülni a pácban.
Az az egyik ok, ami a teljes kód újraírására csábít, hogy az eredeti kód nem arra lett tervezve, ahogy most működik. Indulhatott prototípusnak, esettanulmánynak, tanuló gyakorlatnak, arra, hogy kilenc hónap alatt nulláról eljussunk a részvénykibocsájtásig, vagy csak egyszeri demónak. Mára viszont egy nagy zűrzavarrá nőtte ki magát, aminek működését a hold állása is befolyásolja, bővíteni lehetetlen, mindenki haja az égnek áll tőle, a régi programozók inkább felmondanak, mint hogy ezen kelljen dolgozniuk, a helyükre kerülő újak számára pedig az egész kódnak se füle, se farka. Ezért inkább meggyőzik a vezetőket, hogy mivel az egész úgyis teljesen befuccsolt, kezdjék újra. Ezalatt a Microsoft kis gömböce szőröstül-bőröstül el is nyeli az egész piaci szegmensüket. Ma arról mesélek, milyen más kiutat választhatnának.
„Fogalmam sincs mi a baj a fejlesztőcsapatommal,” – gondolja az elnök-vezérigazgató. – „Olyan jól mentek a dolgok, amikor elindult a projekt. Az első néhány héten a csapat őrülten beindult, és összehoztak egy nagyszerű prototípust. De azóta lelassultak mint a csigák. Egyszerűen már nem hajtanak olyan keményen”. Kiválasztja Callaway Titanium Driver golfütőjét (Callaway Titanium Driver = A golfütők egy olyan típusa, ami annyira jó, hogy már nem engedélyezett a golfversenyeken), és elküldi az inast egy jéghideg limonádéért. „Talán ha a lógósok közül kirúgnék párat, az ismét feltüzelné a többit”.
Te szoftverfejlesztő vagy. Én is. Ám nem biztos, hogy ugyanolyan céljaink és követelményeink vannak. Tulajdonképpen a szoftverfejlesztésből több fajta létezik, és mindegyik külön világra más és más szabályok érvényesek.

Szoftverstratégia madártávlatból – szóval szoftvercéget vezetsz. Hogy hozod stratégiai döntéseid a siker érdekében?

Aki a platform-bizniszben utazik, szenved az úgynevezett tyúk-vagy-a-tojás problémájától. Senki sem veszi meg a platformunkat, amíg nem futnak rajta jó szoftverek, és senki sem ír szoftvert, amíg a platformunknak nincs nagy feltelepített bázisa. Hoppá!
A termékedre áttéréstől való félelem ellen a legjobb módszer, ha lehetővé teszed, hogy visszatérhessenek. Senki sem akar egy olyan termékre áttérni, ami nem nyújt szabadságot a jövőre nézve.
Valójában számtalan remek oka van a programok növekedésének. Először is, ha a programozót nem érdekli, mekkora a kód, előbb tudja szállítani azt. És ez több funkciót jelent, ami megkönnyíti az életünket (ha használjuk), de legalább is általában nem árt (ha nem használjuk). A bloatware és a 80/20-as mítosz
Amint az áramlat magával ragad, már nem nehéz mozgásban maradni. Sok napom a következőképpen telik: (1) beérkezem (2) rápillantok a leveleimre, barangolok a weben, stb. (3) a munka elkezdése előtt még éppen csak ebédelni megyek (4) visszajövök az ebédből (5) rápillantok a leveleimre, barangolok a weben, stb. (6) végre rászánom magam a munkára (7) rápillantok a leveleimre, barangolok a weben, stb. (8) komoly döntést hozok, hogy tényleg el kell kezdenem dolgozni (9) elindítom a nyamvadt szerkesztőt (10) folyamatosan kódolok, majd ráébredek, hogy már este fél nyolc van.
Valahol a 8. és a 9. lépés között van a nehézség, mert nem mindig sikerül átlépni a gátat.
A mikroökonómia kiegészítő termékek elméletében felfedeztem valami érdekeset a nyílt forráskódú szoftverekről: a legtöbb cég azért öl hatalmas pénzeket nyílt forráskódú szoftverek fejlesztésébe, mert ez jó üzleti stratégia számukra. Tehát egyáltalán nem azért, mert megcsömörlöttek a kapitalizmustól vagy elkötelezték magukat a szabad szoftver mellett. Stratégia a színfalak mögött V. rész.
Az Apple-termékek piaci megjelenésekor mindenkinek hatalmas meglepetésben szokott része lenni, még a One Infinite Loop (az Apple-székhely magyarul kb. „Szó köz 1.”-nek megfelelő játékos postacíme – a ford.) kukáit hónapokig megszállottan túró elszánt Apple-rajongóknak is.
A Microsoft ellenben lázasan kibeszéli minden, még akár csak valaki ötletében is létező terméktervét. A .NET-et például cégen kívüli tesztelők a forgalomba kerülése előtt évekig használták.

Melyik a célszerűbb hozzáállás? Érdemes-e hírverés reményében a fejlesztett termék nevét az unalomig elcsépelni, vagy a premierig inkább fogjuk vissza magunkat?
A KTB világában működő üzleteknek van néhány olyan alapvető követelményük, amik nehezen illeszthetők be a vállalkozásokba. Mivel pedig a vállalkozások azok, amik létrehozzák a kockázatitőke által finanszírozott ülzeteket, ez elég nagy probléma.
A Microsofton belül két szembenálló tábor van, amiről kicsit összezárt szájjal csak úgy fogok beszélni, mint a Raymond Chen tábor, és az MSDN Magazine tábor. Hogy veszítette el a Microsoft az API háborút

Egyéb érdekes adatok

Esőben sem lehet olyan gyorsan vezetni, mint száraz időben, legyenek bár a kocsiban ablaktörlők, fényszórók, tető és fűtés, mert elvileg ezek megvédenek az eső hatásaitól (absztrahálják az időjárást), de azért a kocsi megsiklása még nyugodtan előfordulhat, illetve a zuhogó eső erősen lecsökkentheti a látótávolságot is, az időjárást tehát nem lehet teljesen eltakarni A szivárgó absztrakciók törvénye alapján.
Lord Palmerston mondta: „A schleswig-holsteini kérdés annyira bonyolult, hogy az idők során mindössze három európai látta át. Egyikük a néhai Albert herceg volt. A második egy német professzor, aki megőrült. A harmadik én vagyok, de én már elfelejtettem az egészet.” A programozás túl nehéz lett.
A legtöbb felsőoktatásbeli diák hála Istennek van annyira pimasz, hogy ne kérjen tanácsot idősebbektől, ami az informatika területén jó taktika. Az idősebbek képesek olyan ostoba, özönvíz előtti dolgokat mondani, mint hogy „a billentyűzet nyomogató operátorok iránti igény 2010-re eléri a százmilliót” vagy „a LISP szakértők nagyon keresettek most a szakmában”. Tulajdonképpen nekem sincs sok sejtelmem, miről beszélek, amikor tanácsokat osztogatok egyetemistáknak.