Conway's Law v. Software Architecture

http://allankelly.blogspot.com/2013/03/conway-law-...

Efter min mening det bedste citat fra artiklen:

To avoid this my advice is to start a team as small as possible. Try to avoid making architectural decisions in staffing the team by understaffing it. Keeping the team hungry will reduce the possibility of building more than is needed or over architecting it.

Hvis man starter med en enkelt udvikler, så vil den udvikler automatisk opdage når systemet har opnået nok struktur til at det giver mening at tilføje en udvikler mere. Hvis systemet med tiden bliver stort, så vil der på et tidspunkt være flere komponenter som der er brug for at blive udviklet på, hvor opgaverne er så uafhængige at udviklerne ikke vil gå i vejen for hinanden.

Dog kommer arkitekturen også til at afhænge af hvilken udvikler man starter med. Og en person kan begå fejl. Så der kan være en fordel i at have en anden udvikler der kan reviewe både design og kode. Men at starte et nyt projekt med mere end to udviklere fra start af er nok en dum idé.

kasperd (2) skrev:

Men at starte et nyt projekt med mere end to udviklere fra start af er nok en dum idé.

Hvis en eller to udviklere kan klare opgaven: ja.

Langt de fleste problemer i software udvikling opstår når man går fra en eller meget få udviklere til mange.

Men i den typisk situation hvor man skal levere en X mand års løsning på Y måneder med X*12/Y rimelig stor (2-4 cifret) så har man ikke noget valg.

arne_v (3) skrev:

Langt de fleste problemer i software udvikling opstår når man går fra en eller meget få udviklere til mange.

Jeg tror ikke man undgår de problemer ved at sætte alle udviklerne igang helt fra starten af.

arne_v (3) skrev:

Men i den typisk situation hvor man skal levere en X mand års løsning på Y måneder med X*12/Y rimelig stor (2-4 cifret) så har man ikke noget valg.

Et projekt kan være så stort at man er nødt til at sætte mange udviklere på opgaven. Men man skal ikke tro at man altid kan få projektet hurtigere færdigt ved at sætte flere mand på opgaven.

Hvis ikke du har et basalt skellet til systemet at arbejde på, så nytter det ikke at sætte mange udviklere til at arbejde samtidigt. Det resulterer i at alle mangler den samme basale struktur. Det kan i første omgang resultere i dobbelt arbejde, når de alle skal løse den samme opgave. Og ekstra arbejde senere, når det viser sig at de har løst opgaven på forskellige måder. Og man skal fjerne duplikeret funktionalitet for at reducere vedligeholdelsesomkostningerne.

Jeg tror på det er bedre at starte med få udviklere og øge antallet af udviklere gennem forløbet. Mit bedste bud på udviklingen af udviklingsteamets størrelse er noget i retning af en logistisk funktion.

Start med to og så snart man har skellet nok til at kunne dele opgaverne op tilføjer man flere udviklere. Et delteam skal kunne udpege en konkret opgave en ny udvikler kan sættes i gang med før man tilføjer en udvikler mere. Man vil opnå en hierarkisk struktur af teamet, som er modeleret efter arkitekturen af softwaren.

I bunden af hierarkiet har man teams bestående af 2-3 personer hver. Det synes jeg i hvert fald er en passende størrelse for at man kan have noget sparring og så der er nogen til at reviewe koden.