Badare, skogshuggare och objektorienterade designers

Ibland kastas man tillbaka till skolbänken. Inte i bokstavlig mening, som i att gå en kurs, utan bildligen. Ibland blir man påmind om vad man faktiskt lärde sig där bland alla föreläsningar, fikapauser och tentor. Man blir påmind om hur lite man egentligen vet och hur spännande vårt område egentligen är.

Sitter fortfarande med samma avancerade problem som jag bloggade om förra gången. En avancerad urvalsprocess för att välja det bästa alternativet bland många. Jag vet nu vet vad som ska göras och hur det bör gå till men jag hade stora problem med att få lösningen dit jag ville. Jag ritade pilar och boxar, hittade på coola namn som "Manager", "RuleSet" och "Matcher". Problemet jag hade var att det inte kändes objektorienterat. På något vis luktade hela lösningen procedurell kod... Dessutom blev de tester jag skrev krångliga och allt för nyfikna.

Låt oss ta en avstickare och fundera lite över nyfikna tester. De är ett problem. Det är tester som vill veta lite för mycket om klassen som det testar. Istället för att testa inputs och outputs testar de istället hur klassen under test kommer fram till ett resultat. Tänk dig en metod som processar en fil. Den ska givet ett antal villkor ta olika beslut och då och då interagera med andra klasser. Det vi egentligen vill veta är att vår metod uppfyller sitt kontrakt, att den gör det den utger sig att göra. Men ett nyfiket test kollar istället på vilket sätt den interagerar med omvärlden och "tjuvlyssnar" på algoritmens inre logik. Visst, du kanske har snott ihop världens tajtaste algoritm, men jag kan lova dig att det finns någon där ute som kan göra det annorlunda och troligen bättre. Om denne någon fick i uppdrag att modifiera din algortim skulle de nyfikna testerna stå ivägen och bara orsaka svordomar. De skulle faila bara för att man ändrade på algoritmens struktur, fastän det förväntade beteendet var oförändrat. Varje gång vi använder mocks och inte stubs bör vi därför ställa oss frågan: "är jag för nyfiken".

Ok, det var ett sidospår. Jag satt alltså där med en lösning på gång, men med en lukt av gammal unken Pascal.

Återigen ett samtal med en kollega. Återigen en ny syn på saken, men denna gång en sanning jag har kunnat men glömt bort. Frågan han ställde var enkel och förtjänar fet stil i stor font


"Hur skulle det du försöker göra fungera om det gjordes manuellt, i verkligheten?".

En alldeles lysande fråga! Jag tänkte bort alla artificiella saker jag uppfunnit där på min kammare. Jag började förklara flödet och beskrev deltagarna i mitt scenario som personer. Dessa personer hade inga collections eller managers till sin hjälp. De hade böcker, offerter, anteckningar och andra verkliga saker. De interagerade inte med repositories eller factories. De interagerade med andra personer. En skiss dök upp. Pilar fortfarande, men nu streckgubbar och dokument. Regelböcker och arkivmappar.

Det fantastiska med det här var att jag genast fick en objektorienterad lösning. En lösning som modellerade något verkligt och som efterliknade verklig kommunikation och interaktion. Inga Managers, Coordinators eller Services. Helt plötsligt föll sig också kollaboratörernas respektive ansvarsområden och förmågor på plats.

Jag hade helt glömt att objektorientering mår bäst när den modellerar något verkligt. Den mår bäst av att vi inte hittar på massa abstraktioner och flummiga tekniska begrepp. Den mår bäst när vi använder vårt eget språk som vi skulle använda för att beskriva för vem som helst. En snabb tur till Google ger snart denna mening som förtjänar att dammas av: "Software objects are often used to model the real-world objects that you find in everyday life."[källa] Det tål att tänkas på när vi springer iväg med vårt design-pattern-influerade, tekniktörstande ego...

 Vad gäller nyfikna tester slapp jag även dem. Eftersom varje klass nu fick ett tydligt ansvar och tydliga metoder blev det enkelt att testa. Om varje klass får ett tydligt kontrakt är det enkelt att sätta förväntningar och se att de infrias av klassen. Jag tror att nyfikna tester är en indikation på att man pysslar med procedurell kod. Det funkar inget vidare. Tydligen gillar TDD objektorienterad kod bättre än Pascal.

Och så till rubriken. Vad har någon som badar eller kör motorsåg gemensamt med den som sysslar med objektorienterad design? Tja, jag gillar ju både bad och motorsågar (kanske inte i kombination...) men jag är inte den gemensamma nämnaren.

Nä, svaret är enkelt: de är alla saker vi inte bör göra ensamma.

Over and out!
[Dagens kodarmusik: Blow - Ke$ha]

Dags att spela i samma lag!

Min uppfattning om vårt yrke, systemutvecklare, har alltid varit att vi gör mer än att knacka kod. Vi gör mer än att designa mjukvaruarkitekturer. Vi löser behov. Vi utvecklar verksamheten tillsammans med de som arbetar i och med den. Utan dem skulle det inte finnas någon verksamhet, inga behov och inget berättigande för vårt yrkes existens. Tyvärr upplever jag att vi ganska sällan kommer till vår fulla rätt.

Den "färdiga" lösningen på ett fat
Allt för ofta kommer en färdig lösning till oss från användare eller ledning. Det innebär att någon annan än vi har tänkt ut vilket systemstöd som ska finnas och när det måste vara klart. Vi kommer in allt för sent i processen när viktiga beslut redan är fattade som på många sätt inskränker i vår möjlighet att utöva det vi är bäst på - att utveckla IT-stöd. Om vi redan tidigt fanns med i processen kunde vi bättre förstå skäl och bakgrund till det man vill åstadkomma och kanske finna bättre vägar eller ännu bättre lösningar. Men när man får en färdig lösning finns det oftast varken tid eller mandat för att gå tillbaka och riva upp beslut eftersom någon annan ju redan "vet" att det är den enda och bästa vägen. Sen sitter man som utvecklare och knackar ihop något man egentligen inte tror på.

Två månader på IT-kammaren och sen är det klart
Ett annat vanligt scenario är att vi IT-människor får allt för fria händer. Vi tolkar lite tunna uppgifter vi fått för att sedan stänga in oss och designa en lösning som ur vårt perspektiv verkar klockren. Tyvärr slutar det ju ofta med väldigt komplicerade funktioner som användarna inte förstår eller tycker fungerar i deras vardag. De vet inte vad de ville ha, men det som levererades var inte rätt. Lösningen har fått för stort IT-fokus. Fundera en stund över den där dialogen du designade med lite väl "data-nära" termer här och var...

Det här är två ytterligheter, men de pekar båda på samma område där vi allt för ofta brister - samarbete.

Vi måste på ett bättre sätt lyckas använda varandra. De har kunskap om verksamheten och lever i den varje dag. De är beroende av det vi levererar och måste leva med det, varje dag. Vi har kunskap om hur man gör bra IT-stöd, hur man kan samverka med befintliga lösningar och vilka tekniker som är aktuella idag. Var för sig kommer vi till korta, men tillsammans har vi ju en rätt bra laguppställning. Vi täcker ju in alla väsentliga områden! Vore det då inte bättre om vi blev lite mindre DE och lite mera VI?

VI jobbar gemensamt eftersom vi har ett gemensamt mål, en verksamhet som fungerar bra och presterar på topp. Genom att utnyttja våra olika kompetenser och roller på bästa sätt kan vi få mycket bättre effekt och undvika feltolkningar. VI är större än meningslösa motstridigheter, vi bryr oss om vårt gemensamma arbete och vårt gemensamma resultat. Det spelar ingen roll vem eller vad som är skälet till att något inte fungerar eller brister, vi har ett gemensamt ansvar för att få det att fungera.

Det här är några punkter jag tänker arbeta mer för framöver:

• I varje verksamhetsprojekt få med kunskap om IT och möjliga lösningar tidigt
• Upprätta en bra dialog tidigt, lyssna - vad är behovet egentligen?
• Leverera små, körbara, delar av vår lösning regelbundet som vi kan prova gemensamt - på riktigt!
• Aldrig mer säga "ok, då fattar vi" och försvinna in på kammaren och tok-koda i 3 månader
• Aldrig mer säga "ja den lösningen blev ju sådär, men det var ju de på X fel, så det är inte mitt problem"

Vi är ett och samma lag. Vi har ett och samma mål.
Så vad är problemet?

Over and out!

Dagens kodarmusik: Europe - New love in town