Erik Doernenburg, "How Simple is Too Simple?" (Developer Summit)

Developer Summits första dag innehöll två keynotes. Efter Beat Schweglers "Architecting Applications for a Service-Oriented World" var det dags för Thoughtworks-kollegorna Dan North och Erik Doernenburg, men tyvärr kunde inte Dan North infinna sig förrän till fredagens workshop (mer om detta senare). Doernenburg lämnade dock knappast någon besviken när han istället på egen hand besvarade frågan i föredragets titel: "How simple is too simple?"

De flesta är säkert överens om att enkelhet är en eftersträvansvärd kvalitet i mjukvaruutveckling, även vi som emellanåt gör oss skyldiga till det fåfänga misstaget att välja "snygga" eller "smarta" lösningar framför enkla. Även enkelhet kan dock drivas för långt, men frågan är hur enkelt är för enkelt? För att besvara sin fråga ville Doernenburg göra skillnad på enkel ("simple" ) och simplistisk/överförenklad ("simplistic"). En metafor begagnades för att visa skillnaden. Antag att en mur blockerar din väg. En simplistisk lösning är att springa in i muren med full kraft till dess att den rämnas eller nöts ned. En enkel lösning är att ta ett steg tillbaka, konstatera att muren bara är två meter bred och sedan gå runt den.

Motsvarande åtskillnad kan göras mellan komplex ("complex") och komplicerad ("complicated"). Skillnaden i ordalydelse här känns inte lika klockren, men här lutade sig Doernenburg mot Frederick P Brooks särskiljande mellan oavsiktlig ("accidental") respektive väsentlig ("essential") komplexitet för att förklara vad han menar. Exempel på den förra sorten, "komplicerad" med Doernenburgs terminologi, är all kod du för tio år sedan var tvungen skriva för att hämta data från en databashanterare och visa den på en webbsida. Det är här fråga om en komplicerad teknisk implementation och inte om en komplex problemdomän. Ett aktiehandelsystem kan däremot utgöra en mycket komplex problemdomän och då talar vi istället om väsentlig komplexitet ("komplex" enligt Doernenburg).

Efter att ha klargjort dessa distinktioner gick Doernenburg in på lösningar som är för komplicerade ("solutions too complicated") och lösningar som är för enkla ("solutions too simplistic"). Ett intressant exempel Doernenburg lyfte fram på en för komplicerad lösning är när en senior utvecklare med långa bakgrund inom ett företag får för sig att han, istället för att delta i det dagliga arbetet, ska skriva ett ramverk för att underlätta för mindre seniora och/eller nya utvecklare. Ett problem med detta tillvägagångssätt är att det är svårt att veta vad som behöver finnas i ramverket och vad som hör bättre hemma i den konkreta applikationen; det blir i bästa fall kvalificerade gissningar. Man riskerar att på detta sätt öka komplexiteten istället för att underlätta för utvecklarna, inte minst genom att man skapar en abstraktion istället för en konkret lösning. Ett bättre sätt att ta fram ramverk är att "skörda" dem utifrån fungerande praktiker och erfarenheter (se HarvestedFramework). Doernenburg exemplifierade med Spring som växte fram utifrån erfarenheter av vad som saknades i eller inte fungerade med Enterprise Java Beans.

Vi kan säkert alla komma på bra exempel på för komplicerade lösningar, men exempel på för simplistiska lösningar kanske inte poppar upp lika lätt. Ett bra exempel Doernenburg tog upp var transparent distribution av objekt, d.v.s. idén att den som använder ett objekt inte ska behöva bry sig om huruvida objektet instansieras lokalt eller på en annan maskin (via t.ex. .NET Remoting). Detta är en dålig idé eftersom det ofta är av stor betydelse för prestanda om man gör på det ena eller andra sättet och detta bör ha konsekvenser för hur man designar sina objekt (se t.ex. Martin Fowlers First Law of Distributed Object Design: Don't distribute). Ett annat exempel på en simplistisk lösning är att med en O/R-mappers hjälp låtsas att det inte finns någon databas; förr eller senare kommer det att straffa sig, t.ex. i prestandaproblem för vissa typer av frågor som ser enkla ut i objektmodellen men som översätts till mycket komplicerad och krävande SQL. (Detta är inget argument mot O/R-mappers, bara mot ett huvudlöst sätt att använda dem.)

Vad som är enkelt är också relativt. Det som förenklar för en expert kan samtidigt försvåra för en novis. Doernenburg exemplifierade med en kaffemaskin på Thoughtworks som hade sifferkombinationer som gränssnitt. "347" kan t.ex. betyda kaffe med mjölk och socker. Ett tämligen icke-intuitivt gränssnitt för den ovane, men efter en tids tillvänjning kan en person med gott sifferminne, som kanske aldrig annars skulle komma ihåg sina kollegors dryckespreferenser, hämta tio olika sorters kaffe till alla projektmedlemmar genom att memorera några olika sifferkombinationer. Ett mer IT-relaterat exempel är aspektorienterad programmering som för den invigde samlar "cross-cutting concerns" på ett ställe, men som för novisen innebär att man inte förstår vad som händer var.

Ytterligare en viktig aspekt av "enkelt" är den innebörd som är synonym med tidsbesparande. Många utvecklare upplever exempelvis att deras vardag blivit enklare sedan de börjat använda Resharper. "Put effort into being lazy" citerade Doernenburg sin frånvarande kollega Dan North innan han med en summering rundade av sin keynote.

Under denna konferens och vid en del andra tillfällen har jag gjort det till en (o)vana att fråga personer som, precis som Doernenburg, säger sig syssla med objektorienterad och domändriven design och inte har engelska som modersmål vad de anser angående språkval för "ubiquituous language" och därmed kod. Senare under kvällen hade jag förmånen att svinga en bägare med Doernenburg och tog då fram denna käpphäst för en ridtur. Som tysk hade han sett en hel del hemska exempel på tyska utvecklare som efter bästa förmåga suttit med ordböcker för att översätta verksamhetens tyska till engelska. Det säger sig självt att kommunikationen blir lidande med detta sätt och att "hemspråket" oftast är att föredra om man verkligen ska kunna dela modellen med verksamheten.