The real world is a difficult place. So difficult that you sometimes have to work on an old Monolithic application built with legacy technology. But is there a way that allows you to at least share code between the old and the new?

YouYou work as a developer for We’ve All Been There Inc. (WABT Inc.), and you have recently made a new API. This API will serve as a crucial component in WABT’s systems portfolio. Several systems need to integrate with it. Amongst them is “The Monolith” – an application running on .NET Framework (4.8). Your new API is a long step in the direction of splitting The Monolith, but there is still a long way to go. So you've still got to deal with legacy .NET for the foreseeable future.

To enable simple integrations with your new API, you decide to write a C# client library. The library should be distributed as a NuGet package and it has the following requirements:

The client should utilize structured logging for debug and informational purposes.

The team already has a library for logging in NET48, as this is not a native part of the framework: Wabt.Logging

There should be an easy way of integrating the client with Dependency Injection (DI) systems in both NET5.0 (new systems) and NET48.

The Monolith uses Ninject for DI.

Using HttpClient to call an API is straight forward. If it wasn’t for the other requirements, the library would target netstandard2.0 and both it and this blog post would be over:

With the extra requirements, it seems that targeting both net48 and net5.0 is unavoidable. But you don’t like the idea of having #if directives all over the place. Is there any way you can have clean code, that is easy to maintain? Both the shared parts and the framework specifics? Having #if directives everywhere sure isn’t clean, nor easy to maintain. So you need to think smart when solving this.

You decide to get the project file out of the way first. The csproj-file at least has simple constructs to allow you to define multiple TargetFrameworks. You can also define specific dependencies for each target using a Condition.

With that out of the way, you decide to tackle the ApiClient. Inspired by an example from the .NET Docs, your first attempt looks like this:

"Clean code, that is easy to maintain" isn’t what comes to mind when you look at this. There are still features to be added to the ApiClient and there’s #if directives everywhere. There has to be a better way. If you could maybe isolate the parts that are different depending on the target. In this case, that is the logging. So you do what any other great developer would do – you create a wrapper:

Okay, so this approach has an obvious downside. You now have to duplicate every logging method you need instead of leveraging the respective interfaces. But since you only need a few of them, it may be a trade off worth making. Because now, the ApiClient looks like this:

No #if directives! In fact, it is completely oblivious to the multitargeting happening within ClientLogger. All you need to do now is make sure that ClientLogger is wired up in DI whenever someone tries to use the client.

When it comes to DI, the task of supporting Ninject for net48 and the standard IServiceCollection for net5.0 isn’t all that complicated. While the two approaches share the main functionality, they are fundamentally different. So the simplest way is to have two different static classes with extension methods for IKernel and IServiceCollection respectively:

Notice the #if directives. The entire file is dependent on the framework. So the net48 version does not contain ServiceCollectionExtensions.cs and the net5.0 version does not have NinjectExtensions.cs. So now The Monolith can use kernel.AddPingApiClient() and the other applications can use services.AddPingApiClient() - both from the same package.

This approach works well in this particular case. But if there was another project in WABT’s portfolio that has an Autofac based DI-system while also targeting net48, it would be a little messier. This project does not need to reference Ninject. If you find yourself in this position, you are better off splitting the DI-extensions into separate libraries instead. Maybe keep the IServiceColleciton-part in the core library (still for net5.0 only) and make separate ones for Ninject, Autofac and others you need.

When you look back at your multitargeting client library, you realize that your method builds on known principles. Isolate the ugly parts and build neat facades hiding it from the rest. That makes your code easier to maintain. It also makes writing tests simpler. And the best part about that is that you can target multiple frameworks in a test project as well. Running dotnet test will run your tests once for each target. Now you’re thinking with multiple targets!

Multitargeting class libraries in .NET

En klassiker i forbindelse med jobbsamlinger er teambuilding-aktiviteter. Enten det er kickoff eller juleavslutning, er teambuilding et kjent og kjært innslag på programmet. Jeg vil slå et slag for at teambuilding er en unik mulighet som bør utnyttes. 

Siden 2016 har jeg hatt teamlederansvar. Det har blitt en del runder med teambuilding og sosialisering. Begge har sin plass, men jeg synes begrepene ofte sauses sammen. Jeg mener det er en betydelig forskjell: Teambuilding handler om å lære hvordan man er som person og fungerer sammen med andre, mens sosialisering er hyggelig samvær. Min hypotese er at man med noen få, enkle grep kan sørge for at de "myke aktivitetene" man gjør i jobbsammenheng blir effektfulle. La oss ta en titt på utviklingen til et team og hva som kjennetegner høytpresterende team for å få en kontekst.

Å bli kjent som team krever innsats

Å komme sammen som en ny gruppe oppleves ofte som en litt klein greie. Kanskje har man noen som byr litt på seg selv og bryter isen. Kanskje er det en empatisk person som sakte men sikkert varmer opp gruppa med nysgjerrige, genuine spørsmål. Som oftest går det ikke veldig lang tid før man blir litt tryggere på hverandre. Da kommer som regel våre styrker tydeligere frem, spesielt de av oss som er mer selvhevdende enn andre. I min erfaring kan det ta tid før folk finner sin plass i teamet. Bruce Tuckman lanserte en modell for et teams livssyklus i 1965 (wikipedia). Denne har over tid blitt de facto standard for å beskrive et teams utvikling. Fasene jeg beskrev over tror jeg de fleste kjenner seg godt igjen i. Tuckman beskriver disse som forming og storming: Alle er på sin beste oppførsel, før man sakte men sikkert blir tydeligere på hva man mener og hvordan man vil jobbe. 

Jeg skal ikke gå i dybden på denne modellen, det har utallige folk gjort før meg på en bedre måte enn jeg ville fått til her. Poenget er at et team nødvendigvis går gjennom disse fasene før man presterer høyt i fellesskap. Heldigvis kan vi, ved å kjenne til disse fasene, ta målrettede grep for å komme dit raskere. På den måten kan vi akselerere utviklingen til teamet, slik at kalendertiden som går før man presterer høyt sammen, reduseres. 

Medlemmer i høytpresterende team er trygge på hverandre

Et stort buzzword i teamsammenheng anno 2021 er psykologisk trygghet. At det har fått så mye plass ser jeg på som en naturlig motreaksjon mot klassisk ledelse: Her ble man ansett som ressurs heller enn menneske. Jeg opplever at motreaksjoner ofte er emosjonelt drevet og lite fundamentert i rasjonalitet. Det kunne ikke stemt dårligere for psykologisk trygghet! De senere årene har en solid mengde arbeid slått fast hvor viktig dette er for prestasjon i team. Som eksempel vil jeg trekke frem Google. De har i årevis jobbet systematisk for å finne ut hva som gir høy effektivitet. I tråd med hva de finner endrer de praksisene og prosessene sine. Dette initiativet heter re:Work (link), og som del av re:Work publiserte de i 2015 resultatene fra Project Aristotle. Navnet kom fra Aristoteles' sitat: "Helheten er mer enn summen av dens deler". Som navnet tilsier var fokuset deres på team, mer spesifikt hva som kjennetegner høytpresterende team. De konkluderte med at det er fem faktorer, hvor psykologisk trygghet er den viktigste:

Psychological safety was far and away the most important of the five dynamics we found

Du kan lese mer om resultatene deres her. Psykologisk trygghet handler i bunn og grunn om å være trygge på hverandre. Takket være lærdommen og delingskulturen til Google kan vi nå slå fast at dette er en svært sentral faktor for høytpresterende team. Hvis du har to og et halvt minutt til overs vil jeg anbefale følgende video som tar for seg prestasjon vs tillit:

Teambuilding er en unik mulighet til å bygge tillit

Det fine med teambuilding er at vi typisk har koblet oss av det vi ellers gjør på jobb. Vi har satt av tid til å bli bedre kjent. Vi er rett og slett ganske fri fra distraksjoner, noe som i mitt tilfelle er ganske sjeldent i jobbsammenheng. Hypotesen jeg innledet med var at vi med noen enkle grep kan ivareta teambuilding. Med bakgrunn fra Google re:Work vet vi at et av hovedmålene våre her er å bygge trygghet og tillit i teamet. Hvordan gjør vi dette?

Aktiviteter som tar sikte på å bygge trygghet og tillit blir typisk personlige. For at de skal gi verdi må deltakerne være investert: De må ha lyst til å dele. Jeg vil påstå at suksess er når folk gleder seg til disse aktivitetene. Kanskje gruer de seg også litt, for det er jo skummelt å dele. Som klisjeen sier så er det utenfor komfortsonen magien skjer. Du kan tilrettelegge for dette ved å gå foran som et godt eksempel: Vær åpen og personlig, vis at du er sårbar og gi de andre din tillit. Det er en fordel om noen™ har tenkt litt gjennom i forkant hvor teamet befinner seg (ref. Tuckmans modell), samt hva deltakerne er komfortable med. Utvalget av konkrete øvelser og aktiviteter bør reflektere dette. Som teamleder har denne noen™ en tendens til å bli meg, men her vil jeg presisere at dette er et delt ansvar og noe alle kan gjøre. Jo flere som bidrar med åpenhet og deling, jo lettere blir det for resten. 

Sosialisering har absolutt sin plass. Noen ganger kan det være helt perfekt å bowle, eller kanskje dra på MegaZone og skyte hverandre med laserpistoler. Eksempelvis kan dette være en feiring av noe teamet har oppnådd, hvor man ønsker å dra ut et sted og gjøre noe hyggelig sammen. Jeg mener teamet, og teamleder spesielt, er tjent med å ha et bevisst forhold til hva man gjør når, og hvorfor. Mange gode muligheter for teambuilding går tapt når man ikke tenker gjennom hva man vil oppnå og hvordan man bør gjøre det. 

"Dessverre" er det ingen silver bullet for teambuilding. Det finnes ingen konkret oppskrift hvor du gjør A-B-C slik at teamet oppnår høy psykologisk trygghet. Vi kjenner til hvilke momenter vi må ha fokus på, men utover dette er det høyst situasjonsavhengig hva som er hensiktsmessig. Jeg tenker dette er litt av utfordringen og det som er givende med å være leder: Du må bruke den kunnskapen og innsikten du har for å komme opp med gode løsninger. En konkret aktivitet jeg har kjørt et par ganger, gjerne i en tidlig fase for et team, er 36 questions that lead to love (les om bakgrunnen i New York Times: link). Det høres kanskje malplassert ut, men grunntanken er at disse spørsmålene fostrer tillit og skaper trygghet mellom personer. Naturligvis tar jeg ut de mer date-sentriske, men spørsmål som "For what in your life do you feel most grateful?" kan gi svært gode samtaler i min erfaring. 

Mitt håp med denne artikkelen er at du sitter igjen med en bevisst tanke om hva du gjør når og hvorfor med teamet. Kanskje har du også fått litt inspirasjon til å utforske nye aktiviteter? 








19-Dec

Today's posts

Multitargeting class libraries in .NET

Bygger du teamet, eller sosialiserer dere?