Helt ärligt. Ibland måste jag boota upp gamla bettan för att överhuvud taget förstå vad Ayende Rahien jiddrar om. En del kod som han skriver fastnar inte helt naturligt i min hjärna och jag måste lägga en kvart på att fatta vad som egentligen händer... Det kan givetvis vara så att jag är trög, men jag tror inte jag är ensam. Verkligheten på många bolag verkar heller inte vara att de har utvecklare som spottar upp nya DSLr eller kan piska fram en snabb extension method för att möjliggöra test med Rhino Mocks för vårt ASP.net MVC ramverk..

Det företag som ständigt imponerar på mig av många anledningar och där jag även jobbat som konsult en längre tid, har ganska feta system. Hyffsat komplexa, mycket data men nästan inga problem rent incidentsmässigt... Det bara funkar, kanske inte optimalt... Men tillräckligt bra... De har en schysst policy! Håll allt enkelt!!!

I andra företag kan man ha en mindre komplexitet rent affärsmässigt men enorma problem med incidenter för att de levererar skapad komplexitet över sin egen förmåga (som att köpa allt skäggiga snubbar talar om eller inte skriva kod som inte skulle passa som ett inlägg på en IT-alfahannes blogg)... Eller i de fall som är svårast, komplexa system som tillverkas av otroligt välutbildade uggle-människor som gör saker komplexa bara för att det går (som att skriva en egen .net implementation av COM+ eller weirda ramverk för att "skydda" "mindre begåvade" utvecklare från att skriva synkroniseringskod. De aktuella ramverken är oftast utvecklade internt på företaget, skapar ångest hos de som skall använda dem och... Det lustiga är att det nästan alltid blir incidenter i "de begåvade" utvecklarnas ramverk och inte i den kod som använder ramverket... Konstigt...

Sen finns det givetvis otroligt duktiga utvecklare som gör enkla system... Men de är väldigt få (trots scrum, TDD, MSF, BDD och allt vackert)... Jag har långt ifrån något facit på detta men jag är övertygad om att en analys av de incidenter man har i driftsmiljön (och inte enbart skäggiga gubbar) borde ligga till grund för de ramverk / designpriciper / referensarkitekturer som man tillämpar. Av någon konstig anledning sker detta väldigt sällan (eller skapar motsatt reaktion med mer ramverk som kan ##%"/ up).

Snälla, kolla på era befintliga incidenter innan ni lägger upp en plan för ett ramverk som skall "styra upp" hur konsulter och interna resurser skall jobba inom företaget. Och om det är möjligt, strunta i generella ramverk och ha en toolbox med vapen som ni kan använda beroende på vilken uppgift ni skall lösa.

Tänk vad skönt om vi kunde slippa en till våg av n-tier lösningar som skyfflar meninglösa disconnectade recordsets mellan allt för många lager... Men med SOA label denna gång..