sander/notes
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

4pass compiler

Browse source
This commit is contained in:
Shautvast 2024-01-07 16:18:39 +01:00
parent df5b5da679
commit 72a2eb7a0d
1 changed files with 9 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
team topologies/hoofdstuk 1 conway.md
View file

@ -12,7 +12,7 @@ Idee: je zou de werkelijke org struct kunnen reproduceren door de meta data van
-> heeft nog niemand dat gedaan??
monolith/wehkamp
monolieth/wehkamp
Bij wehkamp riepen sommige mensen dat de grote monolitische applicatie opgebroken moest worden in microservices.
Maar waarom?
De applicatie werd onderhouden door 1 team. Is dat niet de belangrijkste aanwijzing?
@ -20,3 +20,11 @@ Misschien moet ik erbij vermelden dat de cognitive load hoog was. Sommige delen
En stel dat je de applicatie openbreekt en zeg in 2 delen splitst. (in casu klant en order). Wat schiet je daarmee op als je niet bijbehorende teams creeert? Maar het geheel werd onderhouden door een man (soms ook vrouw) of 5. Een samenstelling met teams van 2/3 maakt je niet erg flexibel. Waar je uiteindelijk belandt is in een situatie dat je nominaal misschien 2 teams hebt, die in de praktijk maar 1 team zijn, omdat er zoveel interteam communicatie is.
>>'if you have four groups working on a compiler, you'll get a 4-pass compiler' (Eric Raymond)
Hoewel dit niet een helemaal serieus argument is, vraag ik me hierbij toch af hoe tautologisch Conway's law is. Iemand moet toch hebben bedacht dat het zinvol is om 4 teams samen te stellen. En heeft die dan niet gelijk al een intuitie dat een 4-pass compiler een goede implementatie is? Beter gezegd een compiler met 4 kern-functionaliteiten?
Is er dan niet ook ergens in een vroege fase van het project een plaatje gemaakt met dit design?
Hoogstens zou je kunnen zeggen dat een 4-pass compiler extra lastig wordt met 5 teams. En dat er dus alignment nodig is tussen team indeling en architectuur.
Die 'vier teams' is niet zomaar uit de lucht komen vallen, omdat we zeg 20 man beschikbaar hadden, die we op wilden delen.
De 'reverse Conway move' kan ik begrijpen. Dit is het aanpassen van de team samenstelling aan de doelarchitectuur. Want waarom zou je een suboptimale architectuur in het leven roepen, alleen omdat je teams hebt die op een bepaalde manier zijn georganiseerd?
Ì