Produktudviklingens kompleksitetsfaktor

Dette er en tanke jeg har bearbejdet over længere tid. Jeg har bemærket, at et bestemt mønster ser ud til at gøre sig gældende i softwareprodukters levetid. Her tænker jeg ikke på et projekt, som oftest er mere eller mindre planlagt fra start til slut, men på et produkt som udvikler sig løbende i takt med kundebehov og idéer.

I mit simplificerede eksempel, som jeg vil bruge til at beskrive min tanke, antager jeg at produktet opbygges én funktion ad gangen, uden tanke på hvad den næste funktion kunne være. Endvidere antager jeg at alle funktioner i sig selv er lige komplekse.

Det som oftest viser sig at være tilfældet er, at når man skal tilføje den anden funktion til et produkt, tager den alt andet lige lidt længere tid end den første gjorde, fordi den anden skal tage hensyn til den første funktion. Den første funktion behøvede ikke tage hensyn til den anden funktion. Den tredje funktion er endnu mere kompleks at tilføje, fordi den skal tage hensyn til de to første funktioner. Efterhånden som der kommer flere og flere funktioner, bliver de mere og mere komplekse at tilføje – de er ikke i sig selv mere komplekse, men de skal tage hensyn til flere og flere andre funktioner.

Resultatet er en graf som nedenstående, hvor y-aksen er udviklingstimer – d.v.s ressourceforbrug.

Grafen illustrerer ret godt, at hvis man fortsætter med at føje flere og flere funktioner til produktet, bliver hver ny funktion dyrere og dyrere – og omkostningerne stiger eksponentielt!

Mange systemudviklere har umiddelbart mere lyst til at starte forfra på et produkt end at bygge videre på et eksisterende. Årsagen ser du herover. En systemudvikler, som så mange andre mennesker, kan godt lide at se resultater – og resultaterne er sværere at fremvise jo stejlere kurven er.

Ovenstående illustration af produktudviklingens kompleksitetsfaktor er min hovedpointe. Alligevel trænger nedenstående spørgsmål sig på – og jeg vil forsøge at svare på det.

Hvad kan der gøres for at undgå at skulle fortsætte ud af den meget stejle kurve vist herover?

1. Fjern unødige funktioner

Hvis den stejle kurve kan synes uoverstigelig, er det formentlig den hurtigste udvej at fjerne unødige funktioner. Kompleksitetsfaktoren vil stadig være den samme så kurven vil fortsætte uændret, men med færre funktioner at tage hensyn til, vil nye funktioner være simplere at tilføje.

Prisen er selvfølgelig, at man er nødt til at fjerne funktioner, selvom de fungerer helt fint.

Det kan være svært at få sig selv til at acceptere, at man skal fjerne nogle funktioner som fungerer ligesom de skal, men hvis man stiller det op på den måde, at man må vælge mellem de gamle funktioner som ingen bruger og de nye funktioner som alle brugerne skriger efter, bliver valget pludselig lettere.

2. Følg en kodekonvention

En måde at sænke kompleksitetsfaktoren for udviklingen af et produkt er, at følge en kodekonvention. Når alle dele af produktet følger den samme kodekonvention og dermed er mere ensartet, går det hurtigere med at forstå de eksisterende funktioner når der skal udvikles en ny funktion.

Herunder illustreret med en graf, hvor den blå streg repræsenterer nøjagtig samme slutprodukt som den røde, men ved den blå anvendes samme veldefinerede kodekonvention gennem hele produktets levetid.

Der er andre relaterede fordele ved at følge en god kodekonvention, såsom lettere samarbejde mellem forskellige systemudviklere og anvendelse af god praksis som giver et mere langtidsholdbart slutprodukt. Det fantastiske ved at vælge at følge en kodekonvention er, at det ikke tager ekstra tid at gøre det, når de deltagende udviklere først har lært at følge den.

3. Gennemtænkt forarbejde

Selvom man ikke kender den næste funktion i rækken, kan man godt forberede dens ankomst. Det kan man gøre ved at gennemtænke hvordan man opbygger produktet - helst fra starten. Det er forskelligt fra produkt til produkt hvad det vil sige, men basalt set handler det om at bruge noget tid i starten på funktionalitet som forventes at kunne anvendes igen og igen. Det tager lidt længere tid at komme i gang, men til gengæld kan man ved hver ny funktion drage fordel af det arbejde som blev udført i starten.

Det er illustreret herunder med den grønne streg som starter højere oppe, men ikke stiger så hurtigt. Bemærk at den først krydser den røde streg langt henne i produktets udvikling. Hvis man i det tænkte eksempel på forhånd vidste at produktet kun ville komme til at indeholde 5 funktioner, ville tiden som blev forbrugt på det gennemtænkte forarbejde være en dårlig investering. Det er med andre ord ikke altid klogt at tænke tingene igennem før man går i gang. Der kan man bare se.

4. Moduler

Selve problemstillingen i hele denne tanke handler om, at et produkt bliver mere komplekst at udvide jo flere funktioner det består af. Hvis man lader være med at bygge videre på sit produkt, men i stedet starter forfra på et modul som skal anvendes i sit produkt, starter kurven fra 0 igen hvor den er næsten helt flad. Modulerne kan indgå direkte i produktet eller være eksterne moduler som anvender nogle veldefinerede grænseflader. Det kræver man har brugt tid på at muliggøre anvendelsen af moduler i sit produkt.

Det er selvfølgelig kun særlige typer funktioner man kan lægge ud som et nyt modul, så det er ikke så simpelt som det er illustreret herover. Moduler skal indeholde funktionalitet som er afgrænset og som ikke har for mange interaktioner med selve produktet.

I det hele taget er det ikke så simpelt, at man kan vælge én af ovenstående 4 valgmuligheder. Man bør vælge alle 4 og gerne flere.

Er der nogen der har et femte forslag til, hvad man kan gøre for at sænke produktudviklingens kompleksitetsfaktor?