Picture of a forrest with snow and a lot of branches everywhere

The hidden meaning of complexity in the context of software development

Complexity is on the one hand something which can be measured by tools to give an objective value of how complex something is. However, this is not how I’ve come to see the word used in my work as a software developers. In this article I will talk about some of the aspects tucked away in the concept labeled complexity.
It tends to be used to cover up subjective opinions or believes getting portrayed as objective observations. Being able to detect when this happens is an essential skill to ensure you are able to no loose your confidence in your own abilities.

Fear of the unknown 👻

Image of a dark hallway with lights coming out from two open doors leaving two strips of light in the image.
Photo by Kamil Feczko on Unsplash

In my early days as a developer I worked as a contractor on a project for a client where we where hired to get a project over the finish line. They where facing a deadline and needed some people in to product. This was a Microsoft based architecture and it was in the years just after ASP.NET was released. Upon entering the project we learned about the guiding principles by the clients own architect. What we hear left us a bit puzzled as the way in which we where expected to go about coding components and pages went against everything we thought was right. Essentially we had to write our web application as if we where stilling concatenating strings in Perl, but in C# on the .Net platform. We where only two fairly young programmers from our company at the time, but we both thought this looked funny.

We tried to advocate for ASP.NET actually being a productivity enhancement and something which could help us reach the milestones with less effort. Especially since what we where making was a booking calendar solution, which would be ideal for the built in calendar components in ASP.NET. We tried to advocate this and show how it would make things easer, more robust and reduce our time to market. The architect was having none of it. Presenting reasons such as performance and complexity for reasons to keep the current pattern of development.

In reality it turned out to be fear of loosing control and fear of the unknown which lead us to having to implement a solution which was far from ideal and which ended up consisting of way more code than was needed. Writing the calendar booking component in a “Perl-style” was in an objective analysis far more complex and added may more code paths to the solution than the one we presented using the ASP.NET controls. What was diguised as something too complex, was in reality something new and unknown for one individual.

More advanced does not always mean it is more complex

Knowing everything about all different software libraries and frameworks is really hard. Therefor it quite often happens that there are different levels of experience in a team. Developers who’s spent more time with a certain piece of software will know different patterns of how to solve certain things than the novice just learning it.
In cases like this the seasoned practitioner could be faced with their solutions being “too complex”. What the person uttering this often should have said is this: “I was not aware this was a way go about solving this problem. Could you please tell me more”. Figuring out how to best leverage a framework or library takes practice. Especially senior developers are quick to jump to the conclusion of something being “too complex” because they don’t understand something or lack the practice in this particular framework or library.
When encountering this, it’s important to outline how the statement of something being “too complex” is false, it’s just a matter of a more advanced usage of the software we use.

I remember being thought this lesson as a young developer with the attitude and failures of many other young developers: I knew it all. Luckily I had a patient teacher in Per Otto who had the patience and skills to learn me new things. Where I previously would just “hack together” some code, he introduced me to the Gang of Four patterns as a way to more elegantly solve some problems. What looked liked something needlessly complex for me without knowledge of them, turned out to be elegant ways to solve common problems with fewer chance of errors.

Not to my personal taste

Man appearing to be outside is licking on a deadly mushroom.
Photo by Anton Malanin on Unsplash

I have on a few occasions opted to use a framework called Hapi for writing HTTP based APIs in NodeJS. This is not the de-facto option which most developers use (which at the time of writing is Express), but it has some traits I personally really like. With few exceptions the choice of Hapi is always scrutinized by developers accustomed to Express, as they are developed with two totally different philosohpies. Where one is about freedom of choice and providing few opinions in how to do things (Express) and the other is all about making decisions and laying out a preferred path as to how to use the framework to get the most out of it (Hapi).

Being introduced to Hapi is always a bit of a hurdle as there are conventions and ways to do things you just have to accept. If you don’t you will only spend a lot of time fighting a fight you will loose in the end. Most developers opt to follow the path outlined by the author, while others choose to fight the premises on which the framework was authored on every single occasion.

The concept of plugins is central to Hapi and seasoned users of the framework tend to rely heavy on building their solutions as a series of plugins. This concept does not exist in Express and the introduction of writing a piece of domain specific code as a plugin is often met with utterances such as “it is too complex” or “this adds needless complexity to our app”. What I think they actually mean to say is that “this is an unfamiliar approach to solve this issue” and instead opt to solve the problem at hand in their usual manner instead of using the mechanisms built into the framework to solve these things.

What is deemed complex by someone not familiar with the framework, is viewed as an elegant and preferred way by those with more experience in the framework. Writing a Hapi plugin does require some more knowledge, but it follows the architectural patterns outlined by its author.

🎬 In closing

Be on the lookout for the word complexity being thrown around in technical discussions. Much like other powerful words such as performance and security, it is often used to disguise something else.

There are of course some solutions, frameworks and technologies which are more complex (Hello 👋🏼 container managed persistence with EJBs in the Java stack of early 2000s), so there are situations where the argument of something being too complex is appropriate.

A brown cow looking towards the camera with one eye.

Detecting bullshit 🚨

I remember when I first read How To Detect Bullshit by Scott Berkun, I was mesmerized that someone was able to articulate this so well. Throughout my career I have referenced this article to my coworkers. Today, more so than ever before, being able to detect bullshit is one of the most important skills you can have working as a programmer.

An endless stream of bullshit

There is an endless stream of bullshit flowing all over social- and traditional media at any given time. Previously it was not so constant and all consuming, but today you will encounter countless situations where the skill of bullshit detection is required.
If you fail to acquire this skill or do not practice it, you will end up making flawed decisions, make bad choices and maybe you even end up loosing your job over it!

Having a finely tuned bullshit filter is something that requires persistence in this day and age. If you do not force the filter to be applied to all information everything you consume, it will wear you down and you will be one of those people who’s only capable of reiterating something somebody else came up with.

I would argue that in all positions bullshit detection is essential. Obviously it is vital when being in involved in hiring processes. However you need to apply the same filter when working as a programmer and sysadmin. We are all bombarded with trends, hypes and promises of a new silver bullet every single day. A finely tuned bullshit filter is essential to be able to pick out the few important pieces that pass before your eyes during a day. Without it you’ll quickly feel exhausted and get a feeling you are not keeping up.

It only takes one question:

One of the first items in Berkun’s article is this, asking the question:

How do you know what you know❓

It sounds pretty easy, but once you focus upon asking this question every single time someone makes a statement, you will be surprised how often the answer will not be satisfactory.

Always be alert 👀

Let’s say you are visited by someone who’s portrayed as a thought leader in innovation. The first question you should ask yourself should be:
How does this person know what it claims to know?

In an argument with a fellow programmers when someone makes a claim that “X is superior to Y”, your first question should be:
How does this person know this?

drawing of computer program

An approach to problem solving with computer programs

When you start learning to code you develop an idea of what people who does it for a living knows. I remember when I started, I was convinced that everyone around me knew everything and was never in doubt about what the correct approach would be. There was little to read about how to approach coding except for academic articles and books.

In this day and age the situation is very different. There are countless resources where you can see how people approach problem solving using computer programs. You can watch live streams of people working on popular Open Source projects or watch tutorial videos. They all give good insight into the process of coding and shows how you can reason about issues you encounter. One thing you don’t get to see in these rehearsed videos is how they come up with the solutions and how they learned to solve it. In short, you don’t get to see their frantic googling, pulling of hair and general frustration which is usually involved. You don’t see the chat messages discussing topics and expressions of doubts about the solutions.

What I’m getting at, is that there are some things related to problem solving with computer programs which we don’t discuss that often and which is not shown in most coding videos. I will try to outline my preferred way of approaching a problem in an attempt to show that even though I have done this for a living in almost two decades, my approach is not one linear process where I know the steps nor the place I want to end up.

Make it visual

Regardless of wether it is coding up an UI component or creating an API endpoint to solve a data access issue, I have to make it visual. What I mean by that is that I got to draw something somewhere. It could be doodling something on a piece of paper, drawing on a white-board or putting some boxes’n things in a Google slide. This visual I try to update as learn more about the problem I’m trying to solve. More often than not I have to start over. Usually my first assumptions where wrong. That is not a problem! It means I’ve learned something and it’s better to “scrap” a drawing or slide than to revert code changes deployed in production. 

I have met programmers who are able to process things like this in their head. They are able to find design flaws etc by visualising what happens it in their head. This is something I struggle with. I can perhaps “run” a couple of steps of a process in my head, but then I loose it. My short term memory is terrible and I’m also not that great at keeping focus when thinking. Therefor I commit my thoughts to paper or some digital tool. One nice side effect of this is that documentation comes pretty easy, as I’ve been doing that throughout the problem solving process. 

The format in which I draw or the tool I use does not matter, it’s proximity and flexibility that matters. I find modelling tools constraining rather than helpful and enabling. Therefor I tend to use generic tools for visualising / drawing / doodling. There are formal approaches on how to modell software processes and create designs. Personally I find just “drawing whatever” is more useful then ensuring it is 100% correct UML syntax. I am not saying you should not seek learning techniques for modelling software. Everything you can learn which can be added to your toolbox is always worth checking out.

Large problems only? 

My process is the same for wether I’m trying to create some distributed architecture or if it is creating a small UI component. Once the issue requires me to think more than a couple of steps ahead, this is my go to approach and it is something I feel comfortable with. I find that there is no problem too small where this does not help. Sometimes my head just isn’t in it and doing some simple drawings works wonders for me.

Solving the problem

Once the design and preparation is done it is time to solve it. I use similar approach when it comes to writing the code for solving the problem. You can visualise the problem to solve with a drawing, but you can also visualise the flow of a program using text. I learned this approach reading the book Code Complete by Steve McConnel. He said that before writing actual programming statements, you can flesh out the details just using code comments. 

someFunction () {

  // if there is an item
    // render delete button
    // if not render the add button
  
    // write the label of the item
  // then add a parenthesis and a number

}

Once you have got some thing written down, read it back and see if it still makes sense. You should refactor the code block until it makes sense and it does what you meant it to. Perhaps you should extract a method or maybe you need to call out to a service and retrieve some more data. Refactoring when all you have is code comments is easy. As opposed fixing written and deployed code. I’m not saying this is something you must do, it is just one approach which I find helpful at times. 

There are other techniques, such as test driven development, which serves the same purpose as writing code comments before coding (I am aware there are more advantages, but this is not the topic of this post). Others use pseudocode to achieve the same thing (check out Thomas’ post on the topic  “I love pseudocode”). Learning multiple ways to solve problems is useful and something that will be beneficial regardless of the technological platform you happen to be working with.

“Kids, stay in school”

This article contains methods which happen to work well for me. Others will have different approaches and techniques. What is important is staying open minded and stay curious. To keep learning is essential to having a long career as a programmer. 

Hva er en god systemutvikler?

Dusty road in a desert landscape with a car
Veien til å bli en god systemutvikler er hompete, støvete og endere kanskje ikke der du tror.
Kilde: https://www.flickr.com/photos/honzasoukup/2398942904/

Hva er en god systemutvikler? Dette er et ladet spørsmål, så først vil jeg legge ned min definisjon av systemutvikling. Det er et lagspill der man sammen leverer en digital løsning på en utfordring / problem.Legg merke til at jeg ikke sier «hva er en god programmerer». Hvorfor ikke? Fordi programmeringsdelen er bare en  del av det som inngår i systemutvikling. Så, hvilke egenskaper trengs for å være en dyktig systemutvikler i 2018 og i tiden fremover? 

Kommunikasjon 

Du trenger først og fremst å være i stand til å kommunisere med de du jobber med. Det betyr at du kan gjøre deg og dine tanker forstått enten verbalt eller skriftlig. Det er sjelden man sitter alene og utvikler noe uten at man må kommunisere med noen. Dette gjelder både i jobb, men også i stor grad i feks Open Source. En del av det å kommunisere bra er å bli forstått, men også det å gjøre det på en måte som er positiv for de rundt deg. Hvis du sliter med kommunisere det du gjør, tenker eller mener så vil du merke at det å jobbe som systemutvikler kan være frustrende. Å kontinuerlig jobbe med hvordan du kommuniserer muntlig og skriftlig er en veldig viktig det av det å drive systemutvikling. Det er også viktig å forsøke mestre både den uformelle (f.eks chat) og den mer formelle som går på å skrive dokumentasjon eller lignende. 

Empati

Du trenger å være empatisk og forstå de rundt deg. Systemutvikling er å løse problemer for mennesker (startsett, noen ganger å løse problemer for andre maskiner etc men ofte er det mennesker) og da er evnen til å sette seg inn i deres situasjon essensielt. Spesielt i løpet av de siste årene har dette blitt viktig, da teknologien vi utvikler direkte påvirker menneskers lov. Hvis vi som utvikler disse løsningene gjør det uten et snev av empati gjør vi livet til de rundt oss verre, ikke bedre. Systemer utviklet uten tanke på de det påvirker kan få fatale konsekvenser og kan være skillet mellom liv og død (se https://www.nytimes.com/2018/10/15/technology/myanmar-facebook-genocide.html). 

Oppsummert

Kommunikasjon og empati er viktige for å være en bra systemutvikler i tiden fremover. Det betyr ikke at selve faget programmering er uvesentlig og at de to egenskapene jeg nevner gjør at du ikke trenger utvikle den faglige siden av systemutvikling. Det jeg mener er at i tillegg til kunnskaper i faget må du ha menneskelige egenskapene for å være en god systemutvikler. Tiden da systemutvikling var en solo greie er over og kommer aldri tilbake (heldigvis). Ei heller vil tiden da vi laget systemer bare for lolz være det. Det vi lager påvirker verden og menneskene i den, og det ansvaret som ligger på oss som utvikler systemene skal vi ta på alvor.

Kortslutning Podcast har en episode om samme tema, sjekk den ut: “Må du være lidenskaplig opptatt av programmering for å bli en bra utviklar?”

Det å presentere

Jeg var så heldig å få lov til å snakke om noe jeg virkelig synes er spennende på årets JavaZone, nemlig mine erfaringer fra å forsøke skape den nye typen sosiale musikkspiller i foredraget: “How we blew our shot at beating Spotify, spending two metric truckloads of cash doing it”.

En takk går til programkomiteen som lot meg slippe til med et tema som kanskje er litt utenfor, men som likevel så ut til å være spennende for mange. Personlig trodde jeg at det enten ble meg og noen gamle kolleger som kom dit, men det var utrolig gledelig å se et pakket rom. Det var utrolig spesielt å snakke foran en tydelig engasjert gjeng som også stilte en rekke veldig bra spørsmål etter jeg var ferdig, så tusen takk til dere som kom.

Det å presentere

Veldig mange sier at det å holde foredrag handler 80% om det å presentere og 20% om innholdet. Jeg er veldig enig i dette, hvis ikke den som står på scenen faktisk gir av seg selv og forsøker å gjøre det spennende for de som hører på så burde egentlig hele salen gå. Personlig gjør jeg dette veldig ofte, klarer ikke den på scenen å skape en kobling med de som hører på så kan du heller lese slidene etterpå eller se videoen. Du får ingenting ut av å sitte der.

Selvsagt er det utfordringer ved å fokusere mye på hvordan man presenterer, fordi det er ikke alle som da klarer å få med seg hovedbudskapet. Dette forstod jeg da jeg så artikkelen Slik tapte vi for Spotify på digi.no, hvor journalisten hadde valgt å fokusere på de tabloide utsagnene som ikke var en del av hovedbudskapet som gikk på innovasjon og det å starte opp selskaper. Det er selvsagt nyttig erfaring å ta med seg videre og forsøke gjøre det slik at enda fler får med seg det viktigste. Heldigvis var nok journalisten i mindretall, for jeg fikk mange gode tilbakemelding på nettet og fra folk som var i eller hadde jobbet i oppstartsfirma at jeg hadde noen gode poenger.

Hvordan jobbe med presentasjon?

Det er mennesker som skriver bøker om emnet og holder foredrag om nettopp dette. Personlig så har jeg ikke lest noe særlig av slike ting, fordi jeg har en enkel filosofi: Jeg holde kun foredrag om ting jeg bryr meg om.

Dersom jeg skulle holdt foredrag om andre ting, ja så kanskje hadde jeg hatt behov for en metode eller lignende for å komme frem til en presentasjon. Kanskje hadde jeg måtte øve mye og trent på hvordan levere ting. Gitt at jeg alltid snakker om noe jeg brenner for eller som jeg er veldig engasjert i så har jeg ikke behov for noen metode for å komme opp med foredraget (ok, kanskje avsnittene nedenfor kan regnes som en metode, hva vet jeg). Det bare kommer av seg selv, fordi jeg har noe å si.

Til årets JavaZone brukte jeg i underkant av ti timer på å forberede foredraget. Det gikk med litt tid til å få slidene til å matche musikken på introen, men til å sette opp selve foredraget så brukte jeg lite tid. Siste uka før konferansen begynte jeg å sette opp selve presentasjonen. Før det hadde jeg satt opp noen mind maps hvor jeg hadde lagt inn hoved poengene og utover det foregikk forberedelsene i hodet mitt. Jeg føler at det er bedre å gå å gjøre presentasjonen i hodet en del ganger, visualisere hvordan det skal gjøres, fremfor å begynne å hacke ting inn i slides.

Å lage slides er like kjedelig som å skrive manuelle test script

Å lage slides er, for meg, en svært lite kreativ prosess og noe jeg forsøker å bruke minst mulig tid på. Det er som når man skrev stil på skolen og måtte føre inn med penn (ja, så gammel er jeg at jeg ikke kunne levere stil elektronisk). Oppsett av slides er å føre inn for meg, kjedelig men nødvendig likevel. Jeg gjør det slik fordi jeg vil ha mest mulig frihet til å tenke på hvordan ting skal leveres på scenen så lenge som mulig. Det å sette opp slides gjør ting veldig endelig og det er mye jobb å rette opp i ting etterpå. Ved å ha mind maps og ting i hodet så er det ekstremt lett å gjøre justeringer :)

Det eneste som jeg pleier å øve på er introen. Den aller første setningen må sitte og der er det etter min erfaring veldig dumt å ta det på sparket. Kommer du skeivt ut allerede i det du sier hva du skal snakke om, så kan det fort gå bare nedover fra der. Derfor sørger jeg alltid for å ha helt klart for meg hva første setning er. Alt etter det tar jeg på sparket. Å gjøre selve foredraget er noen ganger litt sånn ut av kroppen opplevelse. Det har hendt at jeg har blitt både overrasket og flau når jeg har sett meg selv på video etterpå fordi jeg trodde virkelig ikke at jeg sa det.
Jeg tror at om jeg hadde øvet inn alt jeg skulle si, så hadde ikke foredraget blitt noe bra. Alt jeg øver inn er første setning og etter det ser jeg bare på flyten i presentasjonen og at det er en bra historie som fortelles. Det er langt viktigere at slidene danner en bra ramme som jeg bare kan snakke ut i fra uten å ha trent inn noe.

Sannelig virker det som jeg har en metode likevel når jeg leser dette her, men jeg tror ikke jeg vil anbefale noen andre å følge den. Finn ut av hva du må gjøre for å føle deg trygg når du skal levere noe også gjør du det. Ikke les en bok eller hør på sånne som meg. Lag din egen måte å gjøre det på, så kommer det helt sikkert til å være veldig mye bedre enn å adoptere andre sine metoder. Dette gjelder ikke bare det å gjøre presentasjoner, men også ting som blogg innlegg. Skriver du fra hjertet om noe du brenner for så blir det stort sett bra og folk skjønner det. Ikke hør på en eller annen “kjendis blogger” som skal fortelle deg hvordan du skal gå frem for å skrive blogg. Det er egentlig veldig enkelt: Har du noe på hjertet, så skriv det. Hvis du ikke egentlig har noe å melde, vel så la være å skriv det blogg innlegget. Vi trenger virkelig ikke flere innholdsløse blogger på nettet :)

Kjære konsulent med fin tittel, kom deg ned av scena!

På JavaZone er det ekstremt mange konsulentselskaper som ønsker å profilere seg og det har hjulpet konferansen til å vokse seg til å bli en av de største. Problemet med dette er at de samme selskapene tvinger folk som aldri burde stått foran et publikum til å holde foredrag fordi de har en tittel som tilsier det. Jeg har en bønn til alle dere som tvinger i utgangspunktet veldig dyktige mennesker til å gjøre noe de åpenbart ikke er skikket til. Du bør settes foran et publikum bare fordi du er flink, du skal være foran publikumet fordi du klarer å formidle et budskap. Å kunne lese opp dine egne slides holder rett og slett ikke.

Det handler om å levere

Jeg konstaterte på at det var noe murring om nordmenn som ikke snakket på engelsk og slike ting. Det er godt mulig de snakket om meg også her, for jeg hadde tittel og slider på engelsk men snakket på norsk. Hvorfor gjorde jeg det? Først og fremst av respekt for de som kommer å hører på. Nå tenker du kanskje at det var en rar ting å si ettersom det kan være noen som ikke forstår engelsk i salen. Jeg mener det er bedre å faktisk være i stand til å formidle noe til 80-90% av salen, fremfor å stå der å stotre på håpløs engelsk og bruke all energi på å forsøke å huske hva faen det var du skulle si. Flere foredrag jeg så på JavaZone var på såpass dårlig engelsk at jeg strengt tatt tror de engelsktalende hadde problemer med å forstå det likevel. I tillegg så var det folk som jeg vet kan holde bra foredrag som fremstod som ubrukelige fordi de ikke gjorde det på sitt morsmål.

Derfor mener jeg det er en respektfull ting å gjøre å faktisk innse at, nei jeg kommer ikke til å klare å levere en bra presentasjon som engasjerer de som hører på om jeg gjøre det på engelsk så jeg gjør det på morsmålet mitt. Da er det i vertfall en viss kvalitet på det jeg gjør og jeg kan skape den stemningen jeg ønsker. De som ikke forstår norsk kan forlate salen og heller se på slidene, eventuelt snakke med meg etterpå. Jeg skulle selvsagt ønske at jeg hadde tid til å øve tilstrekkelig slik at jeg kunne gjort foredraget på engelsk, men det var ikke mulig i år. All respekt til de som gjorde det og klarte det bra, dere er mer dedikert og flittig enn meg :)