Joel on Software

Joel on Software   Joel, szoftverekről

 

További "Joel on Software" cikkek magyar nyelven

További "Joel on Software" cikkek angol nyelven

E-mail a szerzőnek (angol nyelven)

 

Fájdalommentes szoftverütemezés


Szerző: Joel Spolsky
Fordította: Plesz Gábor
Szerkesztette: Lászlo Kóvács
29.3.2000

Tavaly októberben az Northeast US vasúttársaság nagy lendülettel hirdetett egy Acela nevű új vasutat, ami Bostonból Washingtonba közlekedik. TV csatornákon, hirdetőtáblákon és posztereken mindenhol. Gondolhatod, hogy ez aztán generált némi keresletet az Amtrak új expressz szolgáltatására.

Nos, lehet. Az Amtrak számára ez soha nem terült ki. Az Acela csak késett, késett, a marketingkampány pedig kifulladt, mielőtt a szolgáltatás valaha is elérhető lett volna. Ez arra emlékeztet engem, amit egy marketingmenedzsertől hallottam, amikor a termékét őrjöngve ismertette egy hónappal a piacra kerülés előtt: „Kiváló a nyilvánosságunk. Milyen kár, hogy még nem lehet megvásárolni ezt a dolgot!”

Tesztoszteron-őrült játékcégek hencegnek weboldalaikon, hogy a következő játékot akkor szállítják, „ha kész”. Ütemterv? Mi a fenének lenne szükség ütemtervre? Mi király játékkódolók vagyunk. A legtöbb cég nem engedheti meg magának ezt a luxust. Kérdezd csak meg nyugodtan a Lotus-t. Amikor először szállították a Lotus-123 3.0-ás verzióját, 80286-os rendszer kellett a futtatáshoz, az pedig nem volt túl elterjedt. 16 hónapig tartott, amíg a terméket sikerült a 8086-osokban lévő 640K memóriába gyömöszölni. Addig, amíg ezzel eljátszottak, a Microsoftnak lett 16 hónap előnye az Excel kifejlesztéséhez. A sors tréfája, hogy közben a 8086 elavult.

Amikor ezeket a sorokat írom, a Netscape 5.0 böngésző közel két éve késik. Részben azért, mert a saját meglévő kódjuk kidobásával és a teljes újrakódolással öngyilkos hibát követtek el és elkéstek: ugyanez a hiba ítélte kudarcra az Ashton-Tate-et, Lotus-t és az Apple MacOS-ét, és juttatta a szoftvertörténelem süllyesztőjébe őket. A Netscape végignézte, ahogy a böngészőjének a piaci részesedése 80%-ról 20%-ra esett, és ez alatt az idő alatt semmit nem tudott tenni a konkurencia ellen, mivel a kulcsszoftvere 1000 darabra szétszerelve hevert a padlón, és sehogy sem tudta feltámasztani egyik pillanatról a másikra. Ezzel az egy rossz döntéssel - sokkal inkább, mint bármi mással - robbantott magára atombombát a Netscape. (A részletekről Jamie Zawinski: világhírű dühroham).

Tehát muszáj ütemtervet készíteni. Ez valami olyasmi, amit semelyik programozó sem akar megtenni. Tapasztalatom szerint a nagy többség megpróbálja megúszni az ütemtervkészítést. Az a néhány, amelyik megpróbálja, csak azért teszi, mert a főnöke kiadta neki, hogy tegye. Készíti is félszívvel, és valójában senki nem hisz az ütemtervnek, kivéve a felsővezetést, aki emellett hisz a „nincs határidőre befejezett szoftverprojekt” alapelvben és az UFÓ-kban.

Miért nem készít senki sem ütemtervet? Egyrészt vesződség, másrészt pedig senki sem hiszi, hogy bármit is ér. Miért vesződne bárki is az ütemtervvel, ha az úgyse lesz jó? Ez az, amitől az ütemtervet folyamatosan rossznak érezzük. És ez csak rosszabb lesz, ahogy az idő halad, tehát minek szenvedni vele?

Íme egy egyszerű és fájdalommentes módszer a folyamatosan pontos ütemtervek elkészítéséhez.

1) Használj Excelt. Ne használj semmi trükköset, mint például a Microsoft Project. A Microsoft Projecttel próbálkozás oda vezet, hogy egy csomó idő elmegy a függőségekre. Függőség az, amikor van két feladatod, és az egyiknek el kell készülnie ahhoz, hogy a másik elkezdődhessen. Tapasztalatom szerint egy szoftverprojektben a függőség olyan nyilvánvaló, hogy mindenféle nyilvántartása csak fölösleges, időrabló tevékenység lenne.

Egy másik probléma a Microsoft Projecttel, hogy ösztönöz rá, hogy megnyomd a kis gombocskát, és „újraszámold/egyensúlyozd” az ütemtervet. Ez szükségszerűen ahhoz vezet, hogy átrendezed a feladatokat, és másvalakihez rendeled, mint eddig. A szoftverkészítésnél ennek semmi értelme. A programozók nem felcserélhetők. Hétszer annyi ideig tart, amíg János kijavítja Rita hibáját, mint amennyi ideig Ritának tartana. És ha megpróbálod a felhasználói felület programozóit ráállítani egy Winsock problémára, egy hetet elvesztesz csak azért, hogy felgyorsítsd a Winsock munkát. A lényeg, hogy a Projectet irodaépületek építéséhez tervezték, nem szoftverkészítéshez.

2) Csináld egyszerűen. Az általános formátum, amit én az ütemtervhez használok, olyan egyszerű, hogy könnyen megjegyezhető. A kezdéshez bőven elegendő az alábbi hét oszlop:

Sample Schedule

Ha több fejlesztőd van, akkor minden fejlesztőt külön lapra tehetsz, vagy egy plusz oszlopba beírhatod a fejlesztő nevét minden feladat mellé.

3) Minden funkció több feladatból áll. A funkció az valami olyasmi, mint hogy helyesírás-ellenőrzőt építesz a programodba. A helyesírás-ellenőrző hozzáadása néhány részfeladatból áll, amit a programozónak teljesítenie kell. Az ütemterv elkészítésének a legfontosabb része ezeknek a feladatoknak az összegyűjtése egy listába. Az alapvető szabály:

4) Csak az a programozó tudja az ütemtervet készíteni, aki a kódot írja. Minden olyan rendszer, ahol a menedzsment írja az ütemtervet és kiadja a programozóknak, végül megbukik. Csak a programozó - aki utánamegy és megcsinálja - tudja elképzelni, hogy milyen lépések kellenek ahhoz, hogy az adott funkciót megvalósítsa. És csak a programozó tudja megbecsülni, hogy mindez mennyi ideig tart.

5) Darabold apró darabokra a feladatot. Ez a legfontosabb rész ahhoz, hogy az ütemterved működjön. A feladatokat órákban kell mérni, nem napokban. (Ha egy olyan ütemtervet látok, ahol a mértékegység nap vagy netán hét, tudom, hogy nem fog működni). Azt hihetnéd, hogy az az ütemterv, amelyikben a feladat jobban fel van darabolva, egyszerűen csak precízebb. Nem! Nagyon hibás ez az elgondolás! Ha elkezded elkészíteni az ütemtervet nagy feladatokkal, aztán szétvágod a feladatokat kisebbekre, eltérő eredményt kapsz, nem csak egyszerűen precízebbet. Egy teljesen más számot. Hogy lehet ez?

Ha teljesen részletes feladatokra csipegeted szét a munkát, akkor rá vagy kényszerítve, hogy ténylegesen elképzeld a lépéseket, amiket végre kell hajtani. Kell írni egy foo() függvényt. Kell egy párbeszédpanel, és így tovább. Be kell olvasni a wawa* állományt. Ezeket a feladatokat aztán könnyebb megtervezni, hiszen már korábban is írtál függvényt, párbeszédpanelt, olvastál be wawa állományokat.

Ha hanyag vagy, és nagy darabokat határozol meg („létrehozni a nyelvi ellenőrzőt”), akkor nem gondolod végig, mit is kell egyáltalán csinálnod. És ha nem gondolod végig, mit is kellene csinálnod valójában, akkor egyszerűen fogalmad sem lesz arról, hogy mennyi ideig fog ez majd tartani.

Ökölszabály, hogy minden feladat 2 és 16 óra között kell, hogy legyen. Ha van 40 órás vagy még hosszabb feladatod az ütemtervben, akkor azt a feladatot még nem daraboltad fel megfelelően.

És egy másik ok, hogy apró darabokra vágd a feladatokat: arra kényszerít, hogy megtervezd azokat az átkozott funkciókat. Ha van egy pompás „internet integráció” nevű funkciód, és azt tervezed, hogy 3 hét alatt elkészíted, akkor elbukod, kishaver. Ha el kell képzelned, hogy milyen eljárásokat kell megírnod, akkor kényszerítve vagy arra, hogy teljesen lefúrjál a funkció legmélyére. Ha ezt előre meg kell tervezned, akkor egy nagy adag instabilitást szüntetsz meg a szoftverprojektben.

6) Tartsd meg az eredeti és a módosított tervet is. Ha először adsz egy feladatot az ütemtervhez, akkor becsüld meg, hogy hány óráig fog a megoldás tartani, és azt írdd be az eredeti terv és a módosított terv oszlopokba is. Ahogy az idő megy előre, ha a feladat megoldása tovább tart (vagy esetleg rövidebb ideig), a módosított terv oszlopot frissítheted, ha szükséges. Ez a legjobb út ahhoz, hogy tanulj a hibáidból, és saját magad megtanítsd, hogyan kell jól tervezni. A legtöbb programozónak fogalma sincs, hogyan találja el, hogy mennyi ideig fog egy lépés tartani. Ez rendben van. Ha hosszú ideig gyártasz ütemterveket, és folyamatosan frissíted ahogy tanulsz, az ütemterv működni fog. (Elhagyhatsz funkciókat vagy megcsúszhatsz, de az ütemterv továbbra is működni fog, azzal a kiegészítéssel, hogy folyamatosan mondja majd neked, hogy el kell hagynod egy funkciót, vagy csúszni fogsz). Azt tapasztaltam, hogy a legtöbb programozó nagyon jó ütemterveket tud készíteni kb. egy év tapasztalat után.

Ha a feladat elkészült, a módosított tervnek és az eltelt időnek egyenlőnek kell lennie, és a hátralévő idő helyére az Excel 0-t számol.

7) Minden nap frissítsd az elvégzett munkával az ütemtervet. Nem kell a stopperórádat nézni, amíg kódot írsz. De közvetlenül mielőtt haza indulsz, vagy az asztal alá fekszel aludni, tégy úgy, mintha ledolgoztál volna 8 órát (há!). Gondold át, hogy mi az, amin dolgoztál, azután ezt a 8 órát szórd szét az eltelt idő oszlopba. A maradék mezőket az Excel automatikusan kiszámolja.

Ugyanekkor frissítsd a módosított terv oszlopban lévő számokat, hogy tükrözzék az új valóságot. Csak két percet vesz igénybe az ütemterv frissítése naponta. Ez az, amiért fájdalommentes ez az ütemterv-készítési módszer - gyors és könnyű.

8) Tegyél be a sorok közé szabadságot, munkaszüneti napot, stb. Ha az ütemterved időtartama már megközelíti az egy évet, valószínűleg minden programozó 10-15 napig vakáción lesz. Ezért kell, hogy legyen az ütemtervedben vakáció, munkaszüneti nap, vagy bármi más, ami egyébként csökkent az emberek munkaidejét. Az ötlet az az, hogy a szállítás napját mindig ki tudjuk úgy számolni, hogy összeadjuk a hátralévő időt, és elosztjuk 40-nel - mindennel együtt pontosan ennyi hét van még vissza.

9) A hibakeresés idejét is számold bele az ütemtervbe! A hibakeresés idejét a legkeményebb megtervezni. Gondolj csak vissza a legutolsó projektedre, amin dolgoztál. Van rá esély, hogy a kód első begépeléséig tartó időhöz képest 100%-200%-ot visz el a hibakeresés. Ez egy fontos elem az ütemtervben, és könnyen lehet, hogy a legnagyobb számokat tartalmazó sor.

Már mondom is, hogyan működik: nézzük a fejlesztőt, aki a wawán dolgozik. Az eredeti terve 16 óra volt, már 20 órája dolgozik rajta és úgy néz ki, hogy még kell 10 óra. Így aztán fejlesztőnk beír 30 órát a módosított tervhez, és 20-at az eltelt idő oszlopba.

A mérföldkő végén mindezen csúszások mellé valószínűleg hozzáad még egy keveset a hibakeresés. Elméletileg, hogy ezeket a csúszásokat elkerüljük, el kéne hagyni funkciókat, hogy időben tudjunk szállítani. Szerencsés esetben az első funkció, amit elhagyhatunk, egy remek nagy funkció, úgy hívják, hogy gyorsítótár (puffer), amire egy csomó órát szántunk.

Elvben a fejlesztő megkeresi a hibát a kódban, amin dolgozik. A fejlesztőnek nem szabad soha, de soha továbbmennie, míg az összes hibát ki nem javította. A hibák száma olyan alacsony kell, hogy maradjon, amennyire csak lehet, két okból:

1) Sokkal egyszerűbb aznap kijavítani a hibát, amikor a kódot írtad. Sokkal nehezebb és több időt vesz el az, ha egy hónappal később javítod ki ugyanezt a hibát. Ekkora ugyanis jó eséllyel már el is felejtetted, pontosan hogyan működik a kódod.

2) Hibát keresni olyan, mint tudományos kutatást végezni. Lehetetlen megbecsülni, hogy mennyi ideig tart a felfedezés és a hiba kijavítása. Ha minden esetben egyszerre egy vagy két hibát kell kiemelni, egyszerű megmondani, mikor lesz a termék szállítása, mivel a jövő nem annyira ismeretlen. Előfordulhat viszont, hogy néhány száz vagy ezer felderítendő hiba van: teljességgel lehetetlen megbecsülni, mennyi idő kell a kijavításukhoz.

Ha a fejlesztők azonnal kijavítják a hibákat, ahogy csak tudják, akkor vajon mire kell a hibakeresés sor az ütemtervben? Nos, még ha minden hibát olyan gyorsan kijavítunk, ahogy csak tudunk, akkor is minden mérföldkő végén kell néhány hibát javítanunk, amikor a (belső vagy béta) tesztelők megtalálják az igazán kemény hibákat.

10) Az integrációhoz szükséges időt is tervezd bele az ütemtervbe. Ha egynél több programozód van, biztosan lesznek olyan dolgok, amit a két programozó következetlen (nem egymással összeférő) módon oldott meg, és ezeket fel kell oldani. Lehet, hogy mindketten ugyanarra az egyszerű feladatra létrehoztak párbeszédpaneleket, melyek feleslegesen különböznek. Valakinek végig kell mennie az összes menün, gyorsbillentyűn, eszköztáron, eszközön, stb. letisztítani és újraszervezni minden újonnan hozzáadott apró-cseprő elemet. Lesznek majd fordítás közbeni hibák, amelyeket mindkét embernek olyan gyorsan, ahogy csak lehet, ki kell javítani. Ahhoz, hogy ezek valóban meg legyenek oldva, be kell vezetni az integrációt az ütemtervbe.

11) Tégy tartalék időt is az ütemtervbe. A dolgok hajlamosak arra, hogy bekéssenek. Van két fontos fajtája a tartalékoknak, amiket érdemes figyelembe venni. Először: tartalékidő azon feladatok nyilvántartásához, amik tovább tartanak, mint előre terveztük. Másodszor: tartalékidő azoknak a dolgoknak, amikről nem is tudjuk, hogy meg kell tennünk, általában azért, mert a vezetés úgy dönt, hogy ennek a wawának a létrehozása ELKÉPESZTŐEN FONTOS, és nem lehet a következő verzióra hagyni.

Lehet, hogy meg fogsz lepődni, a vakációkra, szabadságokra, hibakeresésekre, az integrációra és a tartalékra összesen több időt terveztél, mint a tennivalókra. Ha ez meglepett, akkor nem olyan régóta programozol, ugye? Ha kihagyod ezeket a dolgokat az ütemtervből, akkor magadra vess.

12) Soha, soha ne mondja egy menedzser a programozónak, hogy csökkentse a betervezett időt. Sok kezdő szoftvermenedzser gondolja úgy, hogy „motiválni” tudja a programozóit a gyorsabb munka érdekében azzal, hogy szép „szoros” (betarthatatlanul rövid) határidőket ad meg. Azt gondolom erről a dologról, hogy agyhalál. Ha késésben vagyok az ütemtervhez képest, akkor elátkozottnak, nyomottnak és motiválatlannak érzem magam. Ha ütemterv előtt haladok, akkor derűs vagyok és produktív. Az ütemterv nem pszichológiai játékokra van kitalálva.

Ha a főnököd megpróbálja csökkenteni a tervszámokat, akkor megmondom, hogy mit tegyél. Csinálj egy új oszlopot, amit úgy hívsz, hogy Ricsi tervei (persze feltéve, hogy Ricsinek hívnak.) Ide írd a terveidet. Írj be mindent, amit a főnököd akar a módosított terv oszlopba. Hagyd figyelmen kívül a főnököd terveit. Ha lezárult a projekt, nézd meg, ki van a valósághoz közelebb. Azt tapasztaltam, hogy már ez a fenyegetés is csodát tesz, ha a főnököd rájön, hogy lassúsági versenyt rendeztél.

Miért ilyen ügyetlenek a főnökök, hogy a programozók terveit rövidítik?

Ha egy projekt elindul, a menedzserek elindulnak, találkoznak az üzletemberekkel, és visszajönnek egy funkciólistával. Erről a listáról azt gondolják, hogy kb 3 hónapig tart, de valójában 9 hónapig tart. Ha azt gondolod, hogy kódot írhatsz anélkül, hogy átgondolnád az összes szükséges lépést, akkor ez úgy fog kinézni, mintha n idő kellene hozzá. Ha valóságban megpróbálod létrehozni, akkor valószínűleg 3n ideig fog tartani. Ha valódi ütemtervet készítesz, akkor ahhoz hozzáadsz minden szükséges lépést és feladatot, és ráébredsz, hogy sokkal tovább tart, mint amit eredetileg gondoltál. A valóság hervasztó.

Az ügyetlen főnökök ezt úgy próbálják megoldani, hogy az embereket gyorsabb munkára ösztönözik. Ez nem túl valóságszerű dolog. Felvehetsz több embert, de meg kell várnod, amíg felszívják magukat, addig valószínűleg 50%-os hatékonysággal dolgoznak (és lehúzzák azok teljesítményét, akik őket mentorálják). Akárhogy is legyen, ezen a piacon egy jó programozó betanítása 6 hónapig tart.

Megpróbálhatsz átmenetileg 10%-kal több kódot kihozni az emberekből, de ennek az az ára, hogy egy éven belül 100%-ban kiégnek. Nem nagy gond, csak olyan, mintha a vetőmagot ennéd meg.

De soha nem tudsz 3n-t kihozni n-ből, és ha azt hiszed, hogy igen, akkor e-mail-ben küld el légy szíves a céged tőzsdei rövidítését, hogy még időben léphessek a részvénypiacon.

13) Az ütemterv olyan, mint az építőkockák a dobozban. Ha van egy csomó építőelemed, ami nem fér bele a dobozba, két dolgot tehetsz: szerzel egy nagyobb dobozt, vagy kihagysz néhány építőkockát. Ha szállítanod kell 6 hónap múlva, de 12 hónap áll az ütemtervedben, akkor vagy elhalasztod a szállítást, vagy elhagysz néhány létrehozandó funkciót. Egyszerűen nem tudod összezsugorítani az építőkockáidat. Ha mégis azt színleled, hogy tudod, akkor is csak rosszat teszel magaddal. Megfosztod saját magad a jövőbe látás képességétől, ha magadnak hazudsz arról, amit látsz.

És tudod, az ütemterv-készítés másik nagy előnye, hogy rá vagy kényszerítve a funkciók törlésére. Miért is olyan jó ez? Tegyük fel, hogy van két funkciód: egy olyan, ami igazán használható, és a termékedet igazán pompássá teszi (például a táblák a Netscape 2.0-ban), és egy olyan, amit a programozók szívesen kódolnak (például a BLINK címke a szöveg villogtatásához), ami igazából nem teszi használhatóbbá a terméket, és marketing szempontból sem előnyös különösebben.

Ha nem készítesz ütemtervet, a programozók a könnyű/vicces funkciót fogják először létrehozni. Aztán kifutnak az időből, már nem lesz választásod, és a használható/fontos funkciókat kell elhagynod.

Ha elkészíted az ütemtervet még a munka elkezdése előtt, akkor rá fogsz ébredni, hogy el kell hagynod a tervből néhány funkciót, tehát a könnyű/vicces funkciókat fogod levágni, és csak a használható/fontos funkciókat fogod meghagyni. Mivel rá vagy kényszerítve, hogy válassz néhány funkciót, amit elhagysz, így a termék jobb funkciókészlettel rendelkezik majd, és gyorsabban kerül a piacra.

Emlékszem, amikor az Excel 5-ön dolgoztam. Az eredeti funkciólista roppant hosszú volt, és végig kellett menni az ütemterven. Te jó ég! Gondoltuk. Ezek mind szuper fontos funkciók! Hogyan tudunk majd makrószerkesztő varázsló nélkül élni?

De nem volt más választásunk, elhagytunk minden olyan funkciót, ami nem feltétlenül szükséges. Mindenki boldogtalan volt a vágások miatt. Hogy enyhítsük a fájdalmainkat, egyszerűen azt mondtuk magunk között, hogy nem elhagytuk a funkciókat, hanem átütemeztük őket az Excel 6-ba, mivel kevésbé fontosak.

Amikor az Excel 5 már majdnem készen volt, elkezdtem dolgozni az Excel 6 követelményein Eric Michelman kollégámmal. Leültünk, és végigmentünk az „Excel 6” funkciólistáján, vagyis azokon, ami annak idején kimaradt az Excel 5-ből. Teljesen mellbevágott minket, hogy ez a lista volt a leggyengébb funkciólista, amit csak el tudsz képzelni. Egyetlen egy funkció sem ért semmit. Egyetlen egyről sem gondoltuk azt, hogy valaha is elkészül, még a mostantól számított harmadik verzióban sem. A folyamat, amelynek során elhagyunk funkciókat, hogy az ütemtervet megfelelővé tegyük, a lehető legjobb dolog, amit csak tehettünk. Ha nem tettük volna, akkor az Excel 5 elkészítése kétszer olyan sokáig tartott volna, és 50%-al több hasznavehetetlen funkciót tartalmazott volna. (Egyáltalán nem vagyok meglepve, hogy éppen ez történik a Netscape 5/Mozillával: nem volt ütemtervük, nem volt definiált funkciólistájuk, senki sem akart funkciókat elhagyni, és aztán soha nem is szállították. Amikor meg szállítják, tele lesz olyan funkciókkal, mint az IRC kliens, amivel egyszerűen nem lett volna szabad időt eltölteni.)

Függelék: Amit az Excelről tudni kell

Az okok közül egy, amiért az Excel remek eszköz a szoftver ütemterv kezelésére az, hogy a legtöbb Excel programozó ezt használja saját szoftver ütemtervének a kezelésére. (Közülük nem sok végez üzleti számításokat, mint a „mi lenne, ha” vizsgálatok… ezek itt programozók!)

Közös használat Az Eszközök/Közös használat parancs lehetővé teszi mindenkinek, hogy egyidőben megnyissa ugyanazt az állományt, és szerkessze ugyanazt a dolgot. Egyszerűen az egész csapat tudja folyamatosan frissíteni az ütemtervet. Ez pedig tényleg jó.

Autoszűrő Ez egy kiváló módszer az ütemterv szűrésére, például az összes olyan funkció kilistázására, amit a te neved mellé rendeltek. Automatikus sorbarendezéssel kombinálva meg tudod nézni az összes funkciót, amit hozzád rendeltek, prioritás szerinti sorrendben, ez valójában a tennivalóid listája. Kiráááááály!

Pivot tábla Ez egy pompás módszer összegek és összefüggések megtekintésére. Például egy diagrammot tudsz készíteni minden fejlesztő minden prioritásából hátralévő időre. A Pivot tábla olyan, mint egy falat kenyér. Muszáj megtanulnod hogyan használd, mert ez az Excelt milliószor használhatóvá teszi.

A NETWORKDAYS függvény, mely az Excel Analysis Toolpak csomagjában található, remek eszköz a fájdalommentes ütemterv adatainak naptári dátumokká konvertálására.

* a „wawa” az valami, amit Richard Feynmann híres fizikus használt szövegeiben az „akármi” kifejezésére. Ő úgy használta ezt a szót az angol nyelvben ahogy a matematikusok használják az „x”-et. Mondhatnám azt is, hogy „bla-bla”, de éppen most olvastam egy könyvet Feynmannról!



A fordítás alapjául szolgáló angol cikk címe: Painless Software Schedules  

Joel Spolsky a Fog Creek Software alapítója. A Fog Creek egy apró szoftvercég, székhelye New York City. Joel a Yale egyetemen végzett, majd programozóként és menedzserként dolgozott a Microsoftnál, a Viacomnál és a Junonál.


Az itt olvasható oldalak egyetlen személy véleményét tükrözik.
Minden itt megjelenő tartalom ©1999-2005 Joel Spolsky. Minden jog fenntartva.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky