Computers zijn net mensen. Dit geldt zeker bij een gemiddeld software-engineeringproject: sequentieel werk gaat redelijk efficiënt maar parallellisme vraagt om samenwerken, wat lastig is en overheadkosten geeft. Toch is dat vaak nodig. Anders zou een project van honderd mensjaar een eeuwigheid duren. Of we willen of niet, we moeten het leren: werk opdelen in steeds kleinere brokjes en die brokjes razendsnel en efficiënt verdelen. Zowel in onze programma‘s als bij onze programmeurs.
Er zijn, technisch, vele manieren om parallellisme te organiseren. Elk met hun eigen voor- en nadelen. Zoals de klassieke keuze: multithread versus multiproces. Toen ik nog programmeerde, prefereerde ik processen. Elk stukje functionaliteit in een eigen, stabiel proces met expliciete interfaces in plaats van in threads die ad hoc kunnen verschijnen en verdwijnen. Inmiddels lijken de thread-adepten echter aan de winnende hand. Maar welke vorm van ’multi‘ we ook hebben, de vraag hoe we het werk efficiënt organiseren, staat centraal.
Mijn uitdaging is inmiddels verschoven van techniek naar projecten. Ik heb echter nog steeds dezelfde vraag. Bij projecten spreken we niet over threads of cores, maar over teams en mensen. Die ’verwerken‘ features en taken tot een bruikbaar product. Om de time-to-market laag te houden, zijn ’multi-mensen‘ nodig. Die moeten efficiënt samenwerken, zowel in als tussen de teams.
This article is exclusively available to premium members of Bits&Chips. Already a premium member? Please log in. Not yet a premium member? Become one for just €20 for the first year and enjoy all the benefits.
