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]

Ett par nya ögon och öron kan spela stor roll!

Satt häromdagen och slet mitt hår över en riktigt komplex uppgift. Jag ritade klassdiagram, körde lite TDD, skapade en massa interface.... bara för att inse att jag var ute och cyklade fullständigt. Den känslan är inte ny. Den är tvärtom välbekant.

Jag tror det finns en motsvarighet till författarnas "writers block" även inom vårt yrke. Den där känslan man får när man provat alla angreppsvinklar man har och ändå slutar upp i återvändsgränder. Det är tröstlöst. Det är svårt skadande för självförtroendet. Så ger man upp, slår igen laptopen och slänger sig i soffan med bultande huvudvärk och en känsla av hopplöshet.

Men det tar inte slut där. Då kommer natten. Man vänder och vrider sig och försöker lösa problemet lite sådär halvsovande. Jag minns när jag gick på högskolan och vaknade i flummiga tankar i stil med "hur jag än vänder och vrider på kudden så löser jag inte den här labben". För någon utanför vårt yrke tror jag det låter hur galet som helst. Men jag tror att vi alla har varit där någon gång...

Men sen kommer ljuset - ett par nya ögon eller öron. Man drar ihop en eller ett par kollegor och presenterar problemet för dem. Kanske löser man det bara genom att förklara för dem, genom att höra sina egna ord. Eller så är det någon som bara ser. Ser det du inte kunde se. Någon som får den där förlösande upptäckten som gör att min egen hjärna får en välbehövlig defibliratorchock. Som en LP som hakat upp sig som någon knuffar vidare. Det är en grym känsla!

Ibland är man själv den nytänkande motparten, ibland är man den som kört fast. Oavsett situation är de nya ögonen ovärdeliga.

Dessutom tror jag att man måste igenom det där jobbiga för att kunna ta emot de nya ögonen. Man måste gräva ner sig i ett problem och vända det ut och in före man verkligen kan uppskatta en ny dimension och förstå att den har någon värdefullt att ge.

Precis det här hände mitt senaste problem. En oerhört kreativ diskussion med två begåvade kollegor löste många knutar och någon bara såg. Fantastiskt.

Så alla ni som är med i kreativa diskussioner, se ert värde! Även om man inte kommer fram till lösningen just där och då kan era frågor och nya vinklar vara värda guld. Våga säga nåt, våga komma med en fråga eller åsikt, det kan vara just den som är starten till nästa möjlighet!

Over and out!

Dagens kodarmusik: Sara Lumholdt - Enemy

S - och vad det innebär för oss dödliga utvecklare

Efter att ha hört Hadi Hariri prata om maintainable code på ett event i Göteborg häromdagen fick jag en sista knuff att ta tag i något jag funderat över ett tag, nämligen SOLID.

SOLID är en akronym av akronymer som myntades av Robert C. Martin (Uncle Bob), en levande legend i utvecklarsamanhang och författaren till den fantastiska boken Clean Code. SOLID står för fem principer:

• Single Responsibility
• Open/Closed
• Liskov substitution
• Interface segregation
• Dependency Inversion

Dessa begrepp har många gånger förklarats och diskuterats. Bland annat finns det en hel del referenser till bra podcasts om dem i ett av mina gamla blogginlägg. 

Man kan då undra vilket värde det finns i att gå igenom dem igen, men jag tänkte för egen del ta tag i att lära mig dem en gång för alla. Hur kan jag applicera dem i mitt vanliga utvecklarliv, som affärssystemsutvecklare? Eftersom jag är ett unit-testing freak vill jag också gräva lite i hur väl de sammanfaller med testbarhet.

Därför börjar vi idag med S - Single Responsibility Principle (SRP) som definieras såhär

There should never be more than one reason for a class to change
             (http://www.objectmentor.com/resources/articles/srp.pdf)

En klass ska alltså ha ett enda skäl att ändras. Det klassiska exemplet är en klass "Anställd", som ansvarar för att spara och hämta sig från databasen, räkna ut sin lön och skriva ut en rapport. I ett sånt tillrättalagt exempel är det ju enkelt att se att den har många orsaker att ändra sig. Databasens struktur innebär ändringar. Löneuträkningen innebär ändringar. Rapportformatet innebär ändringar.

Jag tror inte att någon av oss skriver sådana klasser... eller? Ett mer vanligt fenomen är att vi skriver "god-classes", klasser som kan det mesta och lite till. Ett säkert tecken är namnet. När vi känner oss tvungna att lägga på ändelser som "Service", "Manager" eller "Handler" på vår klass ska vi börja fundera. Vad gör vår klass, egentligen?

En annan vanlig sak är att vi smyger in infrastruktur lite här och var, som säkerhet och loggning. Många klasser i systemet  loggar via en logger och varje klass kollar att användaren är auktoriserad. Ändrar vi på någon av dessa tekniker åker vi dit igen. Här kan AOP vara en lösning, men det är en helt annan diskussion.

Ett enklare sätt att titta på SRP är att börja på metodnivå och sedan arbeta sig uppåt. SRP gäller nämligen även där! Här är det ännu enklare att detektera "smells", tecken på att vårat S är i fara:

• Långa metoder
• En metod på 300 rader gör troligen mer än en sak. En metod på 10 rader gör troligen färre saker...
• Otydliga metodnamn
• DoWork() - gör säkert bra saker, men vad? 
• UpdateOrInsert() - gör ju åtminstone två saker
• CreateAndRegisterItem() - dito
• CreateItemIfTotalIsNotTooHigh() - ja, kommentar kanske är överflödig...
• Generells sett, undvik if, and och or i metodnamn...
• Metoder med bool parametrar för att styra flödet
• PrintReport(bool toPrinter) kan ju tydligen skriva ut både till printer och någon annanstans
• PrintReport(bool toPrinter, bool includeDeleted) - mera bools, mera permutationer....
• Metoder som arbetar på flera abstraktionsnivåer
• En metod som läser fil från disk, parsar innehållet och agerar därefter utifrån affärslogik arbetar på flera abstraktionsnivåer och gör definitivt många saker...
  
  

Det enklaste sättet att kolla sig själv är att alltid försöka beskriva exakt vad metoden gör med enbart namnet. Kan man inte det med enkelhet så luktar det lång väg...

När man väl förstår metodnivån kan man dra det längre och applicera det på klassnivå. En Parser klass har ett tydligare definierat ansvar än en FileHandler. Så att försöka namnge saker exakt efter vad de gör är gångbart även på klassnivå.

Ett annat tips som Hadi Hariri tog upp i sin session i Göteborg och i sitt eminenta blogginlägg är att byta ut parametrarna i sina metoder mot instansvariabler. Kolla sedan hur många metoder i klassen som använder dessa instansvariabler. Är det få har vi låg cohesion i klassen, dvs metoderna hör inte ihop. Arbetar de inte på någon instansvariabel kommer Resharper att vilja göra metoden static. Både cohesion och static metoder kan vara tecken på att man bör bryta isär till fler klasser.

Det här innebär givetvis att vi kommer få många små klasser med många små metoder. Ett argument mot det kan ju vara att man inte vill hålla reda på så många klasser i sitt projekt. Men väg det mot att få i uppdrag att lösa en bugg i en klass på 1500 rader, eller en metod på 300 rader... Och det där med att hålla reda på löser de flesta utvecklingsmiljöer rätt bra, dessutom med verktyg som Resharper är varje klass bara ett CTRL+T bort... Så glöm det!

Hur påverkar SRP testbarhet?

• Att skriva test för en metod med tydlig namn och få rader kod är enkelt. 
• Att skriva test för en klass med begränsat ansvar innebär troligen färre beroenden och kollaboratörer. Därmed färre saker att isolera i en testmiljö.
• Små klasser = små testklasser = samma nytta för underhåll som för produktionskod.

Sammanfattning

• Håll koll på namn på metoder och klasser. Är det svårt att komma på = varningslampa!
• Håll metoder och klasser korta
• Granska klassens cohesion
• SRP underlättar testbarhet

Det verkar som om jag kan skriva under på S:et i SOLID. Det är en av de enklare principerna att förstå men kan vara lurigt att implementera. Använd några av teknikerna med namngivning eller instansvariabler till hjälp. Ibland går det inte, men jag tycker att vår ambition är det viktigaste. Att vi förstår att SRP är ett perspektiv att granska sina klasser och metoder utifrån.

Sådär ja! One down, four to go. Next stop: Open/Closed.

Over and out!

[Dagens kodarmusik: Jochen Miller - Brace yourself]

Enkelhet - i all sin enkelhet

Hej, jag heter Per och jag är en "complexoholic".

Okej, det där låter ju lite udda, men jag lyssnade idag på en fantastisk föreläsning av en av mina husgudar, Dan North. Dan pratade om hur vi utvecklare är beroende av komplexitet, hur vi givet ett ganska enkelt problem gärna gör det mer komplext än det borde vara. Vi är "complexoholics".

En av de saker jag tar med mig från Dans presentation är att komma ihåg att fråga mig själv: "varför?". När vi, av ren vana, väljer en lösning bara för att ramverket finns och kan lösa problemet, är det inte alltid det enklaste sättet att lösa problemet. Därför bör vi som utvecklare vara öppna inför varje ny uppgift och inse att den är just det - en ny uppgift. Bara för att den har vissa likheter med vad vi har gjort förut, är den inte samma som vi gjort förut. Därmed kan vi inte alltid förutsätta att vi ska använda samma verktyg varje gång.

Dan gav ett exempel på hur han vek sig själv ut och in när han försökte sätta upp ett test på sin befintliga kod. Efter ett bra tags böjande och "bändande" kom en kollega fram och ställde den magiska frågan: Varför? Några svar och fler "varför" senare valde han, istället för att skriva världens mest komplexa test, att ändra koden så att både den och testet blev enklare.

Genom att ställa frågan till andra och sig själv öppnar man upp ögonen, tar ett steg tillbaka och inser att man löser fel problem. Komplexa lösningar har oftast en mycket enklare och bättre lösning, det gäller bara att hitta problemets kärna.

En annan bra sak att ta med sig är timeboxing. Jag skrev i mitt förra inlägg om risken för att spåra ur när man försöker vara en för bra scout. Den risken minimeras genom att, inför ett problem, ge sig själv en tidsgräns för hur lång tid man har på sig att lösa det. När tiden går ut tar man ett steg tillbaka och tittar ur ett fågelperspektiv och funderar på vad det är som gör att problemet inte är löst.

Många av dessa saker handlar om att öppna ögonen, att bryta invanda mönster och ett rätt så improduktivt beroende av komplexitet.

Sen finns det ju en baksida på att låta enkelheten ta över. Generaliseringar och strävan efter återanvändning är i grunden bra inställningar som vi inte bara ska slänga åt sidan. Ramverk finns för att förenkla och för att skapa en lösning som ser likadan ut överallt. Bara för att en enkel lösning löser problemet innebär inte att vi ska släppa våra kvalitetskrav. Men låter vi oss vara öppna, diskutera med någon annan och ifrågasätta kommer vi långt. Har vi också ett kvalitetsmedvetet, professionellt perspektiv kommer vi ännu längre.

Att vara utvecklare är fortfarande svårt, men faktiskt bara ännu roligare!

Over and out!

Dagens kodarmusik: Within temptation - The heart of everything

Att vara en (för) bra scout...

"The good boyscout rule" betyder att man ska lämna lägerplatsen lite bättre än man fann den. Applicerat till mitt område innebär det att man ska snygga till kod man träffar på lite i taget, så att det successivt blir en bättre kodbas. När jag hörde om denna regel i Robert C. Martins bok "Clean Code" lät det ju helt logiskt. Och det är det. Att hela tiden snygga till den kod man springer på gör saker bättre...

Men (ja, det låg väl ett MEN i luften) det finns problem med att tänka såhär.

Som utvecklare slåss jag hela tiden med instinkten att göra om saker. Göra saker bättre. Göra saker rätt.
Betänk följande situtation och känn om den känns bekant:

Du får i uppdrag att utveckla Feature A. Att göra den rakt upp och ner tar väl någon timme, högst. Men sisådär en kvart in i utforskandet av den befintliga koden har antalet högljudda "nämen va f-n?!" och "WTF!?" blivit så många att du tänker att du kunde gjort det här bättre, snyggare, mer rätt. Ok, du börjar refaktorera. Timme nummer tre in i din omdesign börjar det likna nåt, men det är inte riktigt klart. Bara en stund till... och en till... Till slut har du gjort om designen, men har forfarande inte gjort Feature A klar. Dessutom har du hittat ännu fler saker att göra om och ett antal saker som gör din omdesign omöjlig om inte dessa andra saker också fixas till....

Känns det igen? Här hamnar jag jämt.

Att vara en bra scout som utvecklare kräver en stor dos disciplin. Att kunna göra om lite i taget. Att inse att allt inte kan göras som du vill. Att släppa ifrån dig saker som inte är perfekta. Allt för att få jobbet gjort.

Ok, så vi behöver bli bättre på att lägga band på våra kreativa lust och våra utsvävningar. Men samtidigt är våra instinkter om vad som inte är bra säkerligen befogade. På något sätt måste de komma upp och åtgärdas. Bara inte nu. Inte på bekostnad av Feature A. Inte på bekostnad av sprinten eller projektet.

Kanske är hemligheten att lägga en kvart på att beskriva problemet man hittat i den befintliga designen. Dokumentera det, lägg det i teamets backlog och gå vidare. På det sättet kanske man får ro i den kreativa själen samtidigt som man bibehåller sprinten och projektets fart.

Jag förespråkar inte att man helt bortser från kvalitet, tvärtom. Men rikta insatserna rätt. Exempelvis släpper jag inte på rutiner som unit testing, "clean code" eller "separation of concerns" bara för att trycket är hårt. Det vore bara dumt. Men nyckeln ligger i att ta sig framåt på ett kvalitetsmedvetet sätt utan att helt köra av vägen.

Här ligger vårt paradox:
Vi måste se målet - gå mot det - men utan att tumma på våra principer.
Vi måste bibehålla våra principer - men utan att avvika från målet.

Att vara utvecklare är svårt. Men roligt!

Over and out!
Dagens kodarmusik: Tom Colontonio - Nighthawk (Original mix)

Det vackra i att dölja komplexitet (I'm back!)

Okej. Det var minst sagt ett tag sen. Strunt i det nu.

Idag avslutade jag dagen på topp. Vi vet ju alla att långt ifrån alla dagar på kontoret slutar så lyckligt. Ibland är man mitt i "zonen" när dagishämtningen pockar, ibland är hemgången en ren lättnad efter en dag fylld av motgångar och trassel. Men idag slutade jag på topp.

Jag har insett att min verkliga fetisch inom programmering är att gömma komplexitet. Att generalisera, parametrisera och göra den där svåra saken EN gång. För att jag sen ska utföra samma åtgärd enkelt och helst med en one-liner. Nu innefattande den lösning vi byggde en klass med tre generiska argument och en konstruktor med ett predikat, en func och en action. Snacka om generalitet.

Ok, ibland gör vi dom där generiska klasserna och snurrorna bara för att polera våra egon. Ibland drar man till med en tenär operation bara för att vi kan. Men det som verkligen ger tillfredsställelse är när man använder dessa kraftfulla konstruktioner rätt.


Ibland sysslar vi med copy-paste programmering, vi gör om samma sak om och om igen eftersom det löser uppgiften. Men i de lägena ringer klockan. Här finns chans för generalisering och förenkling.

Jag har jobbat en hel del med Silverlight och MVVM det senaste. I en situation insåg jag att vymodell 2 var till 50% en kopia av vymodell 1. Det var vid tanken att på att skriva exakt samma tester igen eller supporta samma kod på två ställen som gränsen var nådd. Därmed fann jag ett rätt användbart mönster som går att applicera på MVVM med, enligt mig, bibehållen abstraktion.

Om man behöver samma beteende i två vymodeller innebär det med all säkerhet att man har samma beteende i två vyer. Hade detta varit på min gamla WinForms tid hade jag skrikit UserControl för full hals. Ok. Jag skapar en UserControl med det gemensamma beteendet. Nu, för att använda denna UserControl behöver mina vymodeller publicera en 6-7 properties som vyn kan binda till. 6-7 properties i varje vymodell som är duplicerade... RRRRIIIIINNGGG!

Vad jag gjorde var att skapa en delad vymodell för min UserControl som var separat. Denna vymodell innehåller då de properties som behövs. Vymodell1 och Vymodell2 publicerar då bara en property, av den delade Vymodellens typ. Jag sätter DataContext på UserControlen till denna property och voila!

Det som var ännu bättre var att jag lät den delade Vymodellen ta in ett generiskt argument (ok, jag gillar tydligen dom) och därmed kunde operationerna se lika ut medan det som vyn hanterade kunde variera.
Initieringen av den delade vymodellen kan ta in Func eller Action eller Predicate för att utföra specifika åtgärder. Detta bestämmer ju den vymodell som är host, men den gör det deklarativt och EN gång.

Detta är ett mönster som jag med en gång fann mer användning för. Det har säkert ett namn, det är säkert välkänt och det finns kanske åsikter om dess legalitet... men det funkar OCH det låter mig göra saker EN gång.

Låt gå för att denna post kanske var lite mer low-level än annars. Låt gå för att den skulle innehållit kodexempel istället för "lilla sagan om koden". Låt gå. För nu skriver jag av mig tankar igen och det känns grymt!

Over and out!

[Dagens kodarmusik: RAMsterdam - Jorn van Deynhoven remix edit]

Ps. Jag hörde att Silverlight 5 är på gång. Kan det vara sant? Hur fort ska vi byta versioner egentligen! Ds.

Topp 5 podcasts för inspiration!

De senaste månaderna har jag varit en storkonsument av podcasts. Framförallt har det varit Hanselminutes, .Net Rocks, Herding code och MSDN Radio. Med tanke på all den tid jag lägger på pendling och renovering är just podcasts i hörlurarna ett fantastiskt medium.

Det finns såklart avsnitt som är sådär. Avsnitt som handlar om ämnen långt utanför mitt intresse och utanför vad jag riktigt begriper. Men så ibland dyker de upp - guldkornen. Avsnitt jag kan lyssna på igen, avsnitt som verkligen väcker inspirationen och öppnar ögonen.

Jag tror mycket på att vi utvecklare kan tjäna mycket på att dela med oss av det vi kan till varandra. På det sättet kan vi alla växa och göra branschen bättre. Mitt bidrag här och nu är att dela med mig av några riktiga ess bland podcast-avsnitt.

1. Hanselminutes, avsnitt 169: Roy Osherove on The Art of Unit testing

Roy har blivit en av mina hjältar. Han brinner verkligen för unit testing och kan, till skillnad från andra jag hört, verkligen förklara det på en bra och detaljerad nivå. Jag hade dessutom nöjet att se Roy på SDC 2010 där han drog in en humoristisk växel som podcast avsnittet inte visade. Han har vanan att sjunga en liten sång efter sina föredrag där han satt ny text till kända låtar. Vad sägs om "Please don't code tonight" till tonerna av Guns 'n roses "Don't cry"? Tydligen fanns det en utvecklare i hans team med vissa brister... kanske finns den på youtube någonstans...

Men det här avsnittet av Hanselminutes är ett måste för alla oss utvecklare som inte riktigt har kommit igång med unit testing. Kanske också för de som har kommit igång, men som ändå inte har fattat...

Imagine the person reading your tests is a serial killer. You don't want to piss him off.

- Roy Osherove, SDC 2010

2. .Net rocks, avsnitt 476: Is software development too complex?

Detta är en paneldebatt från konferensen Devlink, där panelen diskuterar hur svår och komplex verkligheten är för oss utvecklare. Jag fastnade mycket diskussionen kring hur vi utvecklare ställs inför högt ställda krav på att förstå och anamma ny teknik i en rasande fart. Det här avsnittet har diskuterats en hel del efteråt i andra avsnitt och är definitivt ett man inte ska missa!

3. .Net Rocks, avsnitt 520: Catching up with Juval Löwy

Alltså, Juval... det är en snubbe med rejäl hjärnkapacitet! Här börjar de i en diskussion om Juvals tes "Every class should be a WCF service". Bara att reda ut vad han menar med det gör det här avsnittet riktigt intressant. Sen hjälper det också att intervjuarna Carl och Richard ifrågasätter Juval rätt spydigt... På det hela taget ett mycket bra avsnitt om hur vi utvecklare lägger så mycket tid på "plumbing" och så lite på verklig affärsnytta.

4. Hanselminutes, avsnitt 145: SOLID principles with Uncle Bob

Bara att Uncle Bob är med borgar för bra innehåll, men här tar han upp sina SOLID principles och förklarar dem på ett bra sätt. Om du inte vet vad SOLID är - lyssna! Om du vet vad de är - lyssna ändå, Uncle Bob pratar om dem på ett så självklart vis att du kanske förstår ännu bättre. Avsnittet satte igång en rätt hetsig debatt mellan Bob och snubbarna bakom Stack overflow. Därav blev det en uppföljare med Uncle Bob i avsnitt 150.

5. .Net rocks, avsnitt 470: Nate Kohari on the Zen of project management

Titeln lockade inte först, men det här handlar om lean inom systemutveckling. Nate tillhandahåller en produkt som stödjer "Kanban boards" som en tjänst på Internet. Det intressanta är kanske inte hans produkt utan hela diskussionen kring lean och hur det förhåller sig till agile och scrum. Jag hade inte riktigt koll på begreppen "lean" och "kanban" före jag lyssnade, men nu fattar jag det hela lite bättre. Det gör du också om du offrar 45 minuter!

Det var de fem jag tänkte tipsa om nu. Men det finns många fler som är väl värda sin knappa timma. 

Over and out!

Dagens kodarmusik: In Flames - Moonshield (C64 Version)