Bogen handler software udvikling, primært i store projekter. Bogen er skrevet af Fred Brooks på baggrund af hans erfaringer som projektleder på OS/360 udviklingen – og selvom den er 25 år gammel, så holder den stadig.
Her følger nogle af bogens konklusioner – tilsat mine egne erfaringer som Lotus Notes udvikler igennem 20 år.
1) Dyre produkter
Som programmør kan vi hurtigt lave et program. Hvis programmet skal gøres til et produkt, så stilles der yderligere krav til input validering, test, ui, dokumentation m.v. – og så tager det 3 gange så lang tid at lave.
Ligeledes, hvis programmet skal være en komponent der kan virke sammen med andre komponenter i en større sammenhæng, så stilles der yderligere krav til interfaces, validering, optimering, test og dokumentation. Regn med at det tager 3 gange så lang tid at lave en komponent end blot et program.
Så hvis komponenten skal være et program – så tager det 9 gange længere tid at lave!
Konklusion: Lav kun produkter/komponenter hvis du skal – og ikke kan nøjes med et simpelt program
2) Dyre programmører
Én programmør kan koncentrere sig om at kode – og sikre et konsistent interface. Alt bliver bygget på den samme ide og bliver struktureret ens. Dette er den mest optimale og billigste måde at programmere på.
Hvis der er 2 eller flere programmører på samme projekt – så kommer der automatisk et overhead i form af møder, flere test, mere dokumentation tidligt i projektet m.v. Jo flere programmører jo større bliver dette overhead. Projektet bliver samlet set dyrere – men bliver også hurtigere færdigt (med mindre at der er alt for mange programmører – så kan det ende med at så stort overhead at deadline bliver rykket)
En løsningsmodel kunne være at etablere et ‘Surgial Team’. Her er rollerne fordelt og der benyttes kun én programmør. Resten får støtte funktioner, f.eks. Tool Maker, Debugger, Edtior, Tester etc.
Konklusion: Minimér antallet af programmører på et projekt
3) Dyre linier
Hvis det tager 1 timer at skrive 10 linier kode, inkl test, dokumentation og debug – kan man så lave 100 liner på 10 timer? Nej – erfaringer viser at det tager længere tid. Kurven er eksponentiel.
Konklusion: Skriv ikke flere linier kode end nødvendigt for at løse opgaven
4) Genbrugelig kode
Kode skal genbruges – det sparer tid og giver færre fejl! Men hvis andre skal genbruge din kode – så skal det laves både som et komponent og tager dermed 3 gange længere tid at lave (jvnf punkt 1). Og hvis dokumentationen og tilgængelig ikke er i orden – eller hvis interfacet ikke er intuitivt, så er der en risiko for at koden ikke bliver genbrugt alligevel…
Konklusion: Hvis din kode skal genbruges af andre, så skriv små simple, intuitive komponenter og lav udførlig dokumentation
Citat fra bogen:
”Reuse it something that is far easier to say than to do. Doing it requires good design and very good documentation”
5) Keep It Simple
Så kort kan det opsumeres: “Keep it Simple”. Her et par citater:
- Simplicity is the ultimate sophistication, Leonardo Da Vinci
- Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges and it causes end-user and administrator frustration, Ray Ozzie
- Bad programmers worry about the code. Good programmers worry about data structures and their relationships, Linus Torvalds
- Den nemme løsning er aldrig den rigtige, Jakob Majkilde
- Hvis koden er kompleks – så har du lavet det forkert, Jakob Majkilde
- Complexity and User Experience
- The free lunch is over
- Keep it simple.pdf
- Simplicity is the key: extreme programming