Brooks valt meteen met de deur in huis door een statement te maken dat wij allen projectleiders, teamleiders etcetera al lang vermoeden, maar moeilijk uit kunnen leggen, al helemaal aan onze opdrachtgevers. Het gaat ongeveer als volgt:
- je hebt een software programma; dat is wat een beetje programmeur best handig in elkaar kan knutselen
- je hebt een software product; dat is een programma, met handleidingen, documentatie, getest en al, klaar om te distribueren, met readme’s, disclaimers en wat dies meer zij
- je hebt een software systeem bestaande uit allerlei componenten die met elkaar moeten praten, samen moeten werken, onder een architectuur moeten fungeren etcetera

Een software product kost drie keer zoveel tijd en geld als een softwareprogramma. Een softwaresysteem kost drie keer zoveel tijd en geld als een softwareprogramma. Een softwaresysteem dat als gereed product moet fungeren kost negen keer zoveel tijd en geld als een softwareprogramma. Wat fijn om dat eens te kunnen uitleggen iedere keer als iemand roept: ?¢‚Ǩ?ìdat kun je toch zo wel even programmeren??¢‚Ǩ¬ù

Brooks stapelt de ene na de andere waarheid op. Zo doet hij de volgende magische uitspraken:
- I will contend that conceptual integrity is the most important consideration in system design.
- Adding more manpower to a late software project makes it later (dus niet: ?¢‚Ǩ?ìdan zetten we toch wat mannetjes erbij??¢‚Ǩ¬ù)
- En: de verdeling van de bouw van software is ongeveer: 1/3 ontwerp, 1/6 programmeren, 1/4 component testen, 1/4 systeemtesten. Waarom zie ik altijd in offertes staan 1/6 ontwerp, 2/3 bouw, 1/6 testen?

Brooks is zelfs manager geweest van softwaretrajecten bij IBM. Dat was een aardige leerschool en hij is ook zeker niet te beroerd om zijn eigen fouten toe te geven. In plaats van een genuanceerd beeld, lukt het Brooks toch om heel scherp te blijven. Het boek staat (bewust) vol met boude uitspraken en alhoewel je af en toe wel eens denk ?¢‚Ǩ?ìnou, dat valt toch wel mee?¢‚Ǩ¬ù, is het verfrissend om te lezen (let wel: 1986).

Brooks heeft zo zijn beelden over welke documentatie er moet zijn in een project, de salari?ɬ´ring en carrieremogelijkheden van techneuten ten opzichte van managers en nog veel meer zaken. Hij is bekend geworden door nog wat statements:
- Question: how does a project get to be one year late? Answer: one day at a time. Tijdens een project komt het continu voor dat een vergadering niet doorgaat, dat iemand ziek is, dat iets een dagje te laat is etc. etc. Het is door dit soort dingen dat projecten gigantisch uit kunnen lopen en niet altijd door grote ontwerpfouten of misvattingen. Met andere woorden: die dag vertraging is wel belangrijk en je moet er dus op letten dat dat niet gebeurt!
- plan to throw one away: als je een systeem gaat bouwen, ga ervan uit dat je een versie moet weggooien. Te vaak zie ik dat een zogeheten proof of concept ineens een productiesysteem moet worden met alle rampen van dien.

In 1986 verscheen ook het essay ?¢‚Ǩ?ìNo Silver Bullet?¢‚Ǩ¬ù waar hij zich de woede van menig softwaregoeroe mee op de hals haalde. De nogal suggestieve titel leidt naar het statement dat er in de komende tien jaar tijd geen wonderen verwacht hoeven te worden op het gebied van productiviteit bij softwarebouw. Brooks stelt dat de meeste efficiencyslagen op het gebied van de bouw zelf wel geweest zijn (3gl programmeertalen, hardwareverbeteringen, ontwikkelmethodieken) en dat de enige echte winst nog te halen is in de conceptuele en ontwerpfase. Waarna vervolgens jaren lang allerlei types kwamen met een bewering waarom hun methodiek, programmeertaal, tool, architectuur e.d. wel tot een vertienvoudiging van de productiviteit zou leiden.

In mijn editie van het boek uit 1995 kijkt Brooks nog eens terug, wat er van zijn aloude beweringen uit ?¢‚Ǩ?ìno silver bullet?¢‚Ǩ¬ù en ?¢‚Ǩ?ìthe mythical man-month?¢‚Ǩ¬ù overblijft. Veel. Een deel van de hoofdstukken uit the mythical man-month gaan over echt technische dingen. Zo is er het statement dat je bij het ontwerp van een systeem van te voren targets moet stellen voor het geheugengebruik van de verschillende componenten. Dat is.. laten we zeggen.. wat verouderd.

Veel managementbeweringen echter zijn volgens mijn onverminderd van kracht en Brooks komt ook wel ongeveer tot die conclusie, maar is nog wat kritischer naar zichzelf.. Een punt is dat er veel meer gebruik wordt gemaakt van pakketsoftware dan midden jaren 80. Dit zou je als een enorme productiviteitsverbetering kunnen zien.

En net als je denkt dat je klaar bent volgt er nog een prachtige verhandeling over programmeerteams en wat er voor nodig is om die goed te laten werken.. ik heb gesmuld..

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Keller en co hebben heel veel gedaan in het uitdenken en invoeren van het midofficeconcept bij gemeenten in Nederland, samen met Mark van den Broek van Egem. Het is vast niet helemaal toevallig dat van den Broek nu bij Kellers bedrijf M&I Argitek werkt..

Dit boek is het resultaat van hun denken over midoffices en daarmee een tussentijdse mijlpaal. Alhoewel het uit eind 2006 stamt is het gewoon een duidelijk conceptueel verhaal over de rol van het midoffice bij elektronische dienstverlening door gemeenten. In een lekker tempo wordt je door de ontwikkelingen op dat gebied geleid, door verschillende mogelijkheden en door de verschillende componenten die zich in het frontoffice, midoffice en backoffice bevinden. Alhoewel doorgaans goed leesbaar voor iemand met enige interesse in deze materie, gaat het boek af en toe ook dieper in op technische concepten, bijvoorbeeld rondom web services.

Ik was blij verrast de transparantieprojecten aan te treffen, waarbij Samenwerkende Catalogi zelfs met architectuurplaat en al wordt beschreven en (nog veel mooier) een programma wordt genoemd (voor de leek: het is een project, een programma is doorgaans veel groter opgezet)!

Keller en de zijnen houden het niet alleen bij theorie?ɬ´n: in 2005/2006 hebben ze een aantal toen beschikbare midoffice oplossingen in een laboratoriumopstelling getest op factoren als gebruiksvriendelijkheid, functionaliteit, architectuur en leveranciersondersteuning. Het onderzoek is in 2008 wat gedateerd, maar het beoordelingsmodel is grotendeels nog geldig. Dat onderzoek heeft ongetwijfeld geleid tot wat denkwerk bij de deelnemende leveranciers, waardoor de huidige markt een stuk meer ontwikkeld is.

Het denken over midoffices, dat in dit boek wordt beschreven, heeft bijna rechtstreeks tot gevolg dat een groot aantal gemeenten in Nederland een midoffice oplossing hebben aanbesteed, waarvan steeds meer in een samenwerkingsverband: ANDEZ (afkorting voor Alphen, Nieuwegein, Delft, Ede, Zoetermeer), ANDEZ2, Dimpact en meest recent: Govunited/ANDEZ3.

De echte resultaten van al die projecten zijn nog nauwelijks zichtbaar omdat ze grotendeels nog in een implementatiefase zitten of net draaien. Pas als ze enige tijd in gebruik zijn zal blijken hoe doordacht en hoe praktisch bruikbaar het concept is en in hoeverre de gemeenten in staat zijn het concept door te voeren. Daar gaan we het komende jaar vast veel over horen..

Het boek richt zich wel expliciet op de rol van het midoffice bij elektronische dienstverlening, hoe het midoffice kan worden ingezet bij aspecten als keteninformatisering of integrale besturing van gemeenten komt minder tot niet aan de orde, terwijl ik denk dat hier zeker ook een rol is weggelegd. In het algemeen mis ik een component van rapportages/procesbesturing in het boek, maar gezien de scope en de verdere waarde van het boek kan ik de auteurs dat wel vergeven.

In de tussentijd is dit boek zeker nog een aanrader, met name voor gemeente-ambtenaren die zich met informatievoorziening en ICT bezig houden.

Getting Real is eigenlijk meer een pamflet dan een boek. Ondanks het nogal hoge “wat zijn wij goed”-gehalte, zet dit boek in mijn beleving heel mooi neer hoe je een moderne webapplicatie ontwerpt, bouwt, uitrolt en promoot.

De kern: hou het simpel. Beperk je functionaliteiten, hou je organisatie klein, beperk je functionaliteiten, wees flexibel, werk iteratief, beperk je functionaliteiten en richt je op prioriteiten. En Get Real: hou op met functionele ontwerpen, visies en bla bla en ga schermen ontwerpen, want dat is waar mensen straks op gaan klikken.

Wat maakt 37signals dan zelf? Welnu: Backpack (soort organiser), Highrise (CRM), Basecamp (project managementtool), Tadalist (to do), Campfire (group chat) en Writeboard (online tekstverwerker). Beeldende namen voor tools die je helpen met je productiviteit.

Het leuke aan het boek is dat ze van verschillende kanten naar webapplicaties kijken: interactie-ontwerp, de filosofie achter het product, het ontwikkelproces, de organisatie, de promotie, support.

Joel Spolsky is het er niet helemaal mee eens. En da’s niet zo gek, want hij besteedt op zijn site een drieluik aan hoe je een fatsoenlijk functioneel ontwerp schrijft, terwijl 37signals het hele functioneel ontwerp afschrijft als een waardeloos document.

Wie moet je nou geloven? De waarheid zal soms in het midden liggen, maar soms ook niet. Getting Real is een fris geluid tussen het groffe geweld van afkortingen als ASL, BiSL en RUP en in ieder geval leest het een stuk lekkerder. De auteurs brengen hun eigen filosofie in het boek in de praktijk: het boek is 186 pagina’s, het heeft een mooi groot lettertype, de layout ondersteunt de leesbaarheid ?ɬ®n: iedere stelling heeft hooguit twee a4′tjes nodig.

Ik vond een presentatie op Slideshare over Getting Real, die ik je niet wil onthouden:
Getting Real is online te lezen op http://gettingreal.37signals.com. Ik bestelde de paperback op lulu.com en die is niet al te best qua kwaliteit.

20071223 update: ik las nog een interessante post over de architectuur van 37signals: http://www.highscalability.com/37signals-architecture

Ze introduceren zeven stellingen:

1. Een architectuur is geen project, maar een proces
2. Architectuur is niks nieuws
3. Architectuur is een evolutie
4. De architectuur is niet van de architect, maar van de organisatie
5. Niet iedereen verwacht hetzelfde te lezen in de architectuur
6. De bruikbaarheid van een architectuur is omgekeerd evenredig met zijn omvang
7. Architectuurprojecten zonder echte aanleiding is strafwerk

Laten we voor de grap de zeven stellingen eens toepassen op de NORA:

1. Een architectuur is geen project, maar een proces: “De ontwikkeling van de NORA – door architecten voor architecten – is een continu proces” (van de site) en inderdaad zijn er al meerdere versies verschenen
2. Architectuur is niks nieuws: dat pretendeert de NORA ook niet
3. Architectuur is een evolutie: dat hopen we wel!
4. De architectuur is niet van de architect, maar van de organisatie: “door architecten en voor architecten”.. hmm..
5. Niet iedereen verwacht hetzelfde te lezen in de architectuur: zelf vond ik dit nog niet zo gek verwerkt in de NORA, maar ik hoor ook kritiek dat het vooral op architecten is gericht en niet aansluit bij bestuurlijk denken en operationele uitvoering
6. De bruikbaarheid van een architectuur is omgekeerd evenredig met zijn omvang: 283 pagina’s.. het gaat wel om de hele overheid.. maar eerlijk gezegd is de omvang in ieder geval geen uitnodiging voor mij.
7. Architectuurprojecten zonder echte aanleiding is strafwerk: ik denk dat je al snel een aanleiding kan verzinnen voor een architectuur, zo ook de NORA. Het wordt pas sterk als je ook keuzes gaat maken op basis van die architectuur en mensen het echt gaan voelen.

De stellingen zijn mijns inziens toepasbaar en hebben betekenis binnen de omgeving van Kennisnet maar zijn nog niet meteen heel generiek in de zin dat je een architectuur er op kunt beoordelen. Dat nodigt uit tot verdere uitwerking!

Uit het artikel wordt niet helemaal duidelijk hoe die architectuur er bij Kennisnet uitziet, welke keuzes er zijn gemaakt (keuzes maken = goed idee als je denkt over architectuur). Daar blijf ik benieuwd naar. Wel wordt toegelicht hoe architectuurprincipes worden beschreven, namelijk zo (klakkeloos gekopieerd uit het artikel):

1. Nummer: een uniek nummer waarnaar verwezen kan worden.
2. Principe: het principe zelf. Een kort en krachtig statement
   gevangen in ?ɬ©?ɬ©n zin.
3. Kwalificatie: gericht op architectuurmanagement: hoe
   belangrijk is het om te voldoen aan het principe?
4. Thema: een thematische indeling voor de doelgroepgerichte
   ontsluiting.
5. Uitleg: toelichting op betekenis en begrippen gebruikt in het
   principe.
6. Onderbouwing: het waarom, de rationale achter het principe.
   Dit beschrijft een concern van een stakeholder.
7. Consequentie: indien niet direct vanzelfsprekend: wat zijn de
   consequenties van dit principe? Toegestane implementaties: Welke mogelijke oplossingsrichtingen/ontwerpbeslissingen kunnen worden genomen?
8. Bron: borging van herkomst van principe. Dit geeft de relatie
   aan tussen de architectuur en haar omgeving.

Ik zeg: dat is bruikbaar.

http://www.vka.nl/files/File/Kennisnet_Enserink.pdf

In het begin raakte ik een beetje de weg kwijt. Het boek is opgedeeld in allemaal redelijk kleine passages en die gaan soms qua onderwerp alle kanten op. Als je er eenmaal een beetje in zit komt het allemaal goed. Sterker: het wordt een pageturner, als je ook maar enigszins ge?ɬØnteresseerd bent in dat prachtige complexe proces van software uitdenken, ontwerpen, ontwikkelen, herontwerpen, repareren, herontwerpen, ontwikkelen, vervolmaken, releasen, beheren, managen, herontwerpen, marketen etc…

OSAF, de Open Source Applications Foundation, is een bedrijfje opgericht door Mitch Kapor, oprichter van Lotus. Kapor heeft een droom: een personal information manager waar je echt je leven mee onder controle kan houden, die zo flexibel is dat hij aan al je wensen tegemoet komt en die *in ieder geval beter is dan Outlook en Exchange*. En dan natuurlijk open source, want: dat zou de snelheid van bouwen kunnen verhogen, komt de kwaliteit ten goede en is geek-vriendelijk. Overigens was eerst het plan om een applicatie te maken waar mee je je muziekcollectie kunt beheren. Sorry? Dat doe je toch als je zestien bent? Download.com heeft terwijl ik dit schrijf al 318 Music Managers..

Wat volgt is een redelijk dramatisch verhaal over hoe Chandler (de werknaam) heeeeel langzaam tot stand komt. Begonnen in 2003, de stand van zaken is terwijl ik dit schrijf: in november 2006 is Chandler 0.7alpha4 gereleased, terwijl de oorspronkelijke verwachting ongeveer was dat de 1.0 versie in 2005 opgeleverd zou worden. Pikant detail: 0.7alpha5 zou in juni 2007 worden gereleased en vandaag is het 1 juli. Geen onbekend verhaal in de software wereld en daarom extra mooi om van dichtbij te volgen.

Het project begint met een aantal cracks, die tientallen jaren software-ervaring hebben met Kapor aan de leiding, die schatrijk is geworden door de verkoop van Lotus en wel wat geld over heeft voor een verzetje. Dat kan alleen maar een succesverhaal worden zou je zeggen. Wie schetst mijn verbazing: het is een bedrijf met echte mensen. Echte mensen die ontwerpfouten maken, die vaderschapsverlof nemen, die doordraaien omdat ze in een scheiding liggen, die geen beslissingen durven nemen of eindeloos terugkomen op gemaakte keuzes en die ieder hun eigen stokpaardjes erdoor willen drukken. En die na 4 jaar dus nog geen werkend product hebben opgeleverd.

Tussen de verhaallijn door maakt Rosenberg uitstapjes naar verschillende theorieen over software-ontwikkeling en beheer: CMM, watervalmodel, agile software development zoals SCRUM en Xtreme Programming en niet te vergeten de Mythical Man Month van Frederick P. Brooks.

Mooier nog zijn de wat meer praktische observaties uit de software wereld:

• Linus Torvalds stelling: “Nobody should start to undertake a large project”. Begin met iets kleins en verwacht nooit dat het groot zal worden. Mooi toegepast in de producten van 37signals en haar ontwikkelmethode Getting Real, mooi verwoord in deze presentatie op Slideshare.
• De pijn van het hergebruiken van software: ondanks alle heftige component based development strategieen lukt het ons maar moeizaam. Wordt dat anders met web services?
• YAGNI: You Aren’t Gonna Need It, een fraai principe als iemand weer eens een nieuwe functionaliteit bedenkt die de planning in de war gooit en eigenlijk geen toegevoegde waarde heeft.
• Mijn favoriet: “When the cry of “let’s build it ourselves!” arises, geeks are all too happy to rally and cheer”. Hoe vaak heb ik niet meegemaakt dat er honderden applicaties beschikbaar waren om iets op te lossen, en dat men toch in staat bleek net iets anders te willen en het dan maar zelf te bouwen met als gevolg: mooie beloftes van: “dat kan ik in een uur in elkaar draaien”, enorm veel verloren tijd omdat je opnieuw bouwt wat er al lang is en beloftes en niet te beheren applicaties waar geen enkele documentatie bevatten en die langzaam uitsterven na het vertrek van de bouwer. Grrrrrr..

Mijn eigen observaties:

• telkens als een nieuwe persoon aangenomen wordt op het project zorgt dat voor een boost in de ontwikkeling: Mimi Yin zorgt voor een versnelling van de user interface, Andi Vajda zorgt voor keuzes en snelheid in de database, Donn Denman die de Chandler Presentation and Interaction Architecture vorm geeft en Lisa Dusseault die WebDav standaarden inbrengt. Tegelijkertijd worden daar ook gemaakte keuzes mee overhoop gegooid.
• ze willen teveel: Chandler ontstond vanuit een prachtvisie maar is nu nog niet op het punt dat je daar iets concreets van kan zien. Want: hoe abstracter je visie is, des te meer verschillende meningen er zullen zijn over de invulling..
• ze zijn intern gericht: terwijl web2.0 ontstond, iedereen webbased applicaties ging gebruiken, firefox een grote vlucht nam en gebruikers prima om leerden te gaan met rss en dergelijke, was OSAF aan het nadenken over de Chandler Presentation and Interaction Architecture, whatever that may be.

En dan Chandler het product: in 0.7alpha4 werkt nog veel niet, maar heeft het de potentie een waanzinnig succes te worden? Tsja.. wat ik zie is een gewone agenda. In 2002 overwoog men webbased te gaan of een plugin van mozilla te worden. Mijns inziens was dat een uitstekende keuze geweest, aangezien desktop applicaties imho ten dode zijn opgeschreven.. In het boek worden allerlei features genoemd, waar ik helemaal niet op zit te wachten (en dan beschouw ik mezelf nog als een superuser..). Ik zit overigens wel te wachten op een fatsoenlijke manier om mijn agenda op mijn telefoon, op mijn computer, op mijn kantoor en bij mijn opdrachtgevers fatsoenlijk te syncen. Maar als het ontwikkeltempo van Chandler zo doorgaat, ben ik tegen die tijd uit het raam gesprongen..

Hopelijk wordt mijn cynisme gelogenstraft.

Joel on Software schreef een recensie: http://www.joelonsoftware.com/items/2007/01/21.html

De website van het boek: http://www.dreamingincode.com/

We doen mee om verschillende redenen. Omdat we altijd wel in zijn voor een experimentje. Omdat we de afgelopen tijd wat computerproblemen hebben met laptops die crashen en kapot gaan (niet per s?ɬ© te wijten aan Microsoft overigens). Omdat die Apple’s er zo lekker uitzien… En om twee andere redenen, die mij persoonlijk boeien:

1. Apple Gaat Winnen
2. Wij Willen Webbased

Apple Gaat Winnen
Het aantal Apple gebruikers is in 8 maanden tijd verdubbeld lazen we op DutchCowboys. In maart was ik op een topic maps congres, waar allerlei hipsters met Macs rondliepen en op 1 juni was ik op The Next Web, waar hetzelfde fenomeen zichtbaar was. Hoe kan dat nou? Ongetwijfeld om dezelfde redenen die boven staan, maar om nog ?ɬ©?ɬ©n extra reden: Geeks houden van Apple en gebruikers volgen geeks op termijn. Vroeger hielden gebruikers van Apple en geeks van Microsoft, omdat je op Microsoft zo cool je eigen dingetjes kon tweaken, extra programma’tjes kon installeren en je zo’n domme gebruiker af kon zeiken omdat jij wel wist hoe het moest en zij niet (en op een Apple snapten ze het zelf). En uiteindelijk volgde iedereen de geeks en ging werken op Microsoft.

Dat is nu anders: ten eerste zijn geeks tegenwoordig hip en hippe mensen hebben een Apple. Ten tweede kun je net zo goed programmeren op een Apple als op een PC als je Java, Python, PHP, Ruby of wat dan ook gebruikt (dat was anders in de tijd van Visual Basic en C++). Ten derde omdat de favoriete applicaties van geeks, de open source applicaties als Firefox en OpenOffice, ook gewoon op een Mac draaien. Ten vierde omdat Apple een paar dingetjes heeft waar geeks van smullen: de nieuwe Time Machine, het feit dat ze veel beter met standaarden als iCal en CalDav omgaan. En ten vijfde omdat alles wat echt de moeite waard is op geekgebied zich toch op Internet afspeelt en je dus alleen nog een browser nodig hebt. En dan komen we meteen op het volgende punt.

Wij Willen Webbased
Mijn visie op de automatisering van Zenc is dat alle applicaties waar we als bedrijf van afhankelijk zijn webbased moeten worden, ofwel omdat we gewoon online diensten inkopen, ofwel omdat we eigen applicaties hosted ergens neerzetten. Ik denk dat het domweg niet meer efficient is om zelf applicaties in beheer te hebben en dat de huidige ontwikkelingen, bijvoorbeeld op het gebied van Web 2.0, ASP, Wifi, UMTS, Web Services (om maar wat buzzwords te noemen) ervoor zorgen dat Webbased applicaties binnen afzienbare tijd zo goed zijn dat je het verschil niet meer merkt. En als je alles via de browser doet, dan maakt het niet meer uit of je een PC of een Mac gebruikt.