Don't you ever learn?



Sterk refererend aan deze song van Todd Rundgren:
Dont you ever listen?
Dont you ever learn?
The hand may find you
Its time to take a turn
You think this life is something strange
Youre ready for another change
But dont you ever learn?

Dont you ever listen?
Dont you ever learn?
The world is on fire
Your body doesnt burn
Kill yourself before receiving
Something out of all this breathing
Dont you ever learn?

Don't you ever learn?
Alweer een nieuwe verlosser die deze aarde gaat redden van de crises.
Alweer een meneer met grote beloften.
Er is echter een maar, het zijn slechts woorden.

En op woorden alleen iemand blind volgen, kan gevaarlijk zijn.
Leren van de geschiedenis is niet de sterkste kant van de samenleving.

Het schenkt natuurlijk vertrouwen als iemand in donkere tijden retorisch de kreet "Yes we can" slaakt.
Maar: can we?

De link naar software development is snel gelegd.
Anno 2009 is software bouwen nog net zo'n uitdaging als in de vorige eeuw.
Het is zelfs een steeds grotere uitdaging.
Er zijn nu zoveel talen en technieken met gedeeltelijk loze beloften,
dat de gemiddelde manager denkt dat het gewoon een kwestie van erop los bouwen is.


Voor het gemak, want dat kost alleen maar tijd, wordt een zorgvuldige analyse fase overgeslagen.
Onder het mom van Agile wordt de zorgvuldigheid overboord gegooid.
Lessons learned uit het verleden, worden als legacy bestempeld.
Onnodige ballast voor de zoveelste luchtballon.



Als de roadrunner het niet eerder had meegemaakt, zou hij er moedeloos van worden.
Maar menige déjà vu tart zijn geheugen.
De soep zal wel weer niet zo heet gegeten worden als hij opgediend wordt.

Linke soep is echter dat menig software debacle op het conto van de programmeurs wordt afgeschoven.
Een zwart schaap is snel gevonden.
En de manager, niet gehinderd door enige technische remmingen, kan zijn koers aanhouden.

Zonder gedegen SWAT, wordt het SWOT.
SWAT = http://acronyms.thefreedictionary.com/Strengths,+Weakness,+Advantages+&+Threats+%28assessment%29
of van deze site: Skilled With Advanced Tools (software development)
SWOT = Strengths, Weaknesses, Opportunities and Threats

En dan de variant van de roadrunner:
Simple Waste Of Time

Software bouwen kan veel efficiënter als op voorhand de zaak goed doordacht wordt.
Maar al te vaak is het een rush.
Bob de bouwer ten top.

Hier een stukje uit de blog van Sander (http://sanderhoogendoorn.org/blog/?p=13
Overijverig
Zo zijn wij als developers nagenoeg voortdurend overijverig in ons streven de klant te plezieren; vaak nog meer dan de klant verwacht. “Een eenvoudig overzichtje is prima hoor, we hoeven echt niet zo’n 3D pie chart waarin we kunnen downdrillen.” Ooit heb ik dit het Bob de Bouwer-syndroom gedoopt. Wij kunnen alles maken! En anders bedenken we wel dat de allernieuwste versie van onze tools het probleem oplost. “In de nieuwste versie van Visual Studio is workflow veel betere geïntergreerd.” Dat deze nieuwste versie van Visual Studio pas in beta is en voorlopig nog niet verschijnt, is natuurlijk bijzaak.

Het voorbeeld is gedateerd, maar het syndroom is nog steeds actueel.

Zie ook http://www.cs.kuleuven.be/cs/alg-info/indepers/archief/softwareproblemen.shtml

En er loopt nog meer verkeerd. Hoogendoorn: ,,Softwareontwikkelaars leiden soms aan een 'Bob de Bouwer' syndroom.'' Bob de Bouwer is de huizen bouwende en reparerende ster van een tv-reeks voor kinderen. Zijn helpers, een stel sympathieke pratende machines, roepen bij elk bouwprobleem uit: ,,Bob de Bouwer, kunnen wij het maken? Bob de Bouwer?'' Waarop het antwoord luidt: ,,Nou en of!'' Softwaremakers hebben volgens Hoogendoorn ook bij elk nieuw idee een reflex van 'dat maken we wel even'. Ze gaan meteen enthousiast aan het knutselen, terwijl de prioriteiten misschien beter elders zouden liggen.

En dan is er nog de tijdsdruk voor de ontwikkeling van commerciële softwarepakketten, de ' rush to market '. Berbers: ,,De tijdsdruk is heel hoog. De fabrikanten willen bijvoorbeeld hun pakket gereed hebben voor de eindejaarsperiode. Dat maakt de druk op de ontwikkelaars heel hoog. De tijd die je spendeert aan het correct schrijven van programma's, is tijd die niet onmiddellijk rendeert.''

Hoe deze negatieve spiraal te doorbreken?
Door te luisteren naar jezelf.
Het klinkt simpel, maar ga er maar eens aan staan!

Hoezo moet het allemaal zo snel?
Als deze software echt zo belangrijk was, waarom is hij dan niet veel eerder gebouwd?
En betaalt de investering in goed geschreven doordachte software zich niet vanzelf terug?
Maandenlang debuggen en fixen is zonder meer zondetijd.

Liever goed dan snel.
Ook al is de eis: snel en goed.

En dezelfde vragen kun je stellen bij het testen en documenteren.

Kortom: laat het verstand regeren en niet de waan van de dag.
Want de waan van de dag is morgen weer een andere.