Programmører vil ikke arbejde "gratis"...

Brian Knudsen:

Hvor er selve processen dækket ind henne af ? Kender mange programører, både erfarne og uerfarne der bare kaster sig over projektet og siger det har vi klaret inden måneden er omme; 6 mdr senere sidder der en ide mand der ikke fatter hvad det skete og hvorfor koden ikke kan det han drømte om, på den anden side af bordet sidder der en irriteret programmør  der bare ikke gider flere tilføjelser / rettelser, men begge parter har ikke brugt tiden til at få lavet en opskrift på det produkt i vil have sat i søen, herefter ender resten af projektet oftest i den uendelige diskution om hvem der var amatør og hvem der havde sit på sit tørre. Resultat = alle taber

En ting man bør vide om programmører er at vi stort set allesammen er usandsynligt dårlige til at estimere, især store opgaver. En af de største grunde til dette er at bygge software ikke er som at bygge en bro, man møder ikke brobygnings-projekter, hvor det halvvejs gennem projektet bliver besluttet der skal bygges en tunnel i stedet for. Men det er slet ikke uset at selv de mest fundamentale requirements til et stykke software ændrer sig undervejs, fordi en stor del af de markeder som software benyttes til bevæger sig lynhurtigt. I teorien kan det i software verdenen sagtens lade sig gøre at "lave en bro om til en tunnel", det kræver dog en god udviklingsprocess og nogle meget dygtige folk i alle roller der er involveret i projektet.

Der findes et hav af softwareudviklingsprocesser og hvilken en der er bedst til et specifikt projekt afhænger af folkene, produktet, miljøet, tidsrammen, dokumentationskravet, m.m.

Brian Knudsen:

Så tag lige og få noget respekt for hinandens evner, og til programmørerne; i fejler lige så meget ved at gå ind i et projekt der ikke er dokumenteret inden i går igang! Hvor tit har i set et hus blive bygget op uden en arbejdstegning først ? Til idemagerne kan jeg kun sige, næste gang i sætter en programmør igang med et projekt for jer, så sørg for en dokumentation der svare til en bagevejledning eller guiden fra legoklodserne. Programmøren skal ikke være i tvivl om funktionaliteterne i jeres projekt.

Jeg har stor respekt for dygtige forretnings-, process- og idé-folk med evnerne i orden, som taler lige ud af posen, men ingen tålmodighed med det modsatte. Jeg er sikker på at der findes uduelige programmører og er selv stødt på nogle stykker i min tid som software udvikler, dem har jeg heller ingen tålmodighed med. Sagen i Nordeuropa, især i de store byer, er p.t. at udbuddet af talentfulde programmører er lille mens efterspørgslen er stor. Omvendt er der et utal af mennesker med en idé til et produkt, der kræver en eller flere programmører, de talentfulde programmører er der få af og de vælter i gode tilbud. Det er et spørgsmål om udbud og efterspørgsel.

Mht. til at have dokumentation af det ønskede produkt i samme detaljegrad som en "bagevejledning", så lyder det meget i retning af Vandfaldsmodellen, som af gode grunde har været i stærk tilbagegang i de seneste år. I et marked hvor kravene skifter lige så hurtigt som vejrudsigten, ender du med at være færdig med din "bageopskrift" på samme tidspunkt som din konkurrent er i færd med at lancere hans tiende version af sit konkurrerende produkt, som allerede har kunder og har været igennem 10 vigtige iterationer, med værdifuld kundefeedback, hvor uønskede features er skåret fra og ønskede features er forbedret eller tilføjet.

Valget af udviklingsprocess afhænger som nævnt tidligere af mange faktorer, men i en marked hvor tingene går hurtigt, vil jeg til enhver tid foretrække en iterativ udviklingsprocess.