Developer Summit, dag 1

Utöver de båda keynotes jag skrivit om tidigare (Beat Schwegler och Erik Doernenburg) bjöds det på en del andra intressanta föredrag under Developer Summits första dag.

Tess Ferrandez - "Common problems in ASP.NET Production environments"
Jag har länge sporadiskt följt Tess Ferrandez blogg "If broken it is, fix it you should". Ferrandez är Escalation Engineer på Microsoft Product Support Services och hennes bloggande syftar till att hjälpa .NET-utvecklare "resolve issues on production system, mainly using Windbg.exe from http://www.microsoft.com/whdc/devtools/debugging/default.mspx along with sos.dll that ships with the debugging tools". Det var precis vad hennes session på Developer Summit handlade om också. Det är egentligen inte något av mina främsta intresseområden, men jag har alltid fascinerats personer som förstår vad som händer under huven och obehindrat kastar sig över textbaserade konsolapplikationer med kryptiska kommandonamn och switchar. Ferrandez talade samtidigt som den till synes intressanta arkitektsessionen "The New Role of the System Architect" med Kentors Peter Tallungs och Visabs Fredrik Wahlstedt, men jag valde Ferrandez eftersom man aldrig vet när hon kommer till Sverige igen medan åtminstone Tallungs dyker upp lite här och där. Döm därför om min förvåning när Tess Ferrandez inleder på svenska och berättar att hon jobbar på Microsoft i Kista! Jag har tydligen läst hennes blogg lite för sporadiskt för där kan man tydligt se att hon är svenska (och spanjorska).

Ferrandez delade in sitt föredrag i tre delar: Performance Issues, Memory Issues och Crashes and Exceptions. Det verktyg hon använde för att analysera problemen inom alla områden var det tidigare nämnda WinDbg. Med detta program kan man bl.a. se exakt hur många instanser av olika objekttyper som ligger på heapen, hur stort ett enskilt objekt är och skriva ut ett objekts innehåll. För den som är intresserad av den här typen av frågor, har problem med ASP.NETs minneshantering, laddning av assemblies etc, eller vill lära sig mer om WinDbg kan jag rekommendera en närmare titt på "If broken it is, fix it you should", där man också kan hitta mycket av innehållet från Ferrandez session.

Jimmy Nilsson – "Beyond Agile"
Jimmy Nilsson har tidigare gästat Avega och jag läste med stort nöje hans senaste bok, så det var med stor förväntan jag såg fram emot hans föredrag med det spännande ämnet "Beyond Agile". Han började lite trevande och konstaterade att allt fler arbetar agilt nu för tiden; men har verkligen de agila metoderna löst alla våra problem? Frågan är förstås retorisk och med utgångspunkt i ett antal problemområden gav Nilsson sin syn på vad han skymtar bortom de agila metoderna.

"Teamwork doesn't work"
"Requirement descriptions are poor"
Ett sätt att komma till rätta med dessa problem är BDD, Behavior-Driven Development. BDD handlar i sin enklaste och ursprungliga form om ett annat sätt att tänka testdriven utveckling (TDD). Istället för att formulera testerna som "TestWithdraw" bör man formulera dem som "CanWithdrawMoney", "ShouldIssueWarning" o.s.v. I ett lite större perspektiv handlar det om att definiera acceptanskriterier i ett tidigt skede, göra det på verksamhetens språk och göra kriterierna exekverbara. Ett exempel på hur det skulle kunna se ut:

"Money can be withdrawn"
GIVEN
Account has money
Card is valid
WHEN
Card is inserted
Money is requested
THEN
Card is output
Money is output
Account is credited

Nilsson gav inget exempel på något verktyg eller någon miljö där detta är möjligt, men mina tankar under föredraget gick till FitNesse som jag länge tänkt titta närmare på. Med tanke på vad Dan North tillkännagav och Jimmy Nilssons kollega Niclas Nilsson bloggade om härom dagen antar jag emellertid att rbehave var vad han hade i tankarna. Med denna form av BDD skulle också testarna kunna komma in tidigare i projektet än vad som ofta är fallet i många utvecklingsprojekt, något som kanske kan bidra till att stärka teamkänslan och samarbetet.

"Lack of focus on understanding the domain"
"Focus on large scale and overview is missing"
Domain-Driven Designs (DDD) fokus på problemdomänen och på ett gemensamt språk för verksamheten och utvecklingsteamet kan vara en lösning på dessa problem. Vad gäller ett mer övergripande perspektiv och DDD kan man konstatera att Eric Evans ägnar ett antal kapitel i sin bok "Domain-Driven Design" åt "strategic patterns"; Nilsson berättade att Evans sagt att om han skulle skriva om boken i dag skulle han lägga denna del först, istället för som nu sist, i boken. Jag kommer att återkomma till DDD och dessa strategiska mönster i en separat bloggpost om Evans bok, men tills vidare kan jag varmt rekommendera boken för den som vill veta mer.

"Developers get partly wrong tasks"
"'Wrong' abstraction level is used"
Vi behöver inte nödvändigtvis högre och högre abstraktioner, utan rätt abstraktion. ("Att abstrahera högt är stort, men att abstrahera rätt är större" för att parafrasera den devis av Thomas Thorild som pryder ingången till Uppsala universitetshus aula. J) Det här är något som Nilsson varit inne på redan i sin senaste bok och som också berördes av andra under Developer Summit. Här lyfter Nilsson fram domänspecifika språk (Domain Specific Languages, DSL) som ett motmedel. DSL:er är egentligen inget nytt utan handlar om att skapa problemspecifika "programmeringsspråk" som bättre än de generella uttrycker problematiken i en särskild problemdomän, gärna på ett språk som ligger nära domänexperternas. Språket behöver inte nödvändigtvis vara textbaserat utan kan bestå av diagram, t.ex. de som användes för arbetsflöden i Windows Workflow Foundation. För Nilssons del är säkert tankarna kring DSL kopplade till DDD:s betoning av "ubiquitous language" och vad Martin Fowler och Eric Evans benämner "fluent interfaces", men det är också en viktig beståndsdel i Microsofts satsning på software factories.