The Developer Domain

I have programmed in one way or another more or less my whole life. Starting with Basic on the C64. It evolved to assembler and Pascal on the Commodore Amiga. Later I moved on to C and more modern programming languages.

“Modern” programming languages have provided us with many things. Some of them very useful that made developers job much more convenient. While others, in my opinion, have had the complete opposite effect.

For a long time I reveled in objects, interfaces, inheritance, abstractions, design patterns, uml design etc etc. Having a “real” engineering background design patterns appealed to me. They felt like a mechanical blueprint or a mathematical formula.

In reality, the concept of design patterns have disappointed me. I have experienced good projects where design were carefully planned and governed by skilled architects. But, in my opinion, this is rare. In many companies design is equal with a large number of abstractions that create a overly complicated  object hierarchy that provide little or no business value. And the architects, they are developers that just worked there long enough.

In many workplaces developers establish a hero status by creating overly complicated software that other developers have a hard time understanding. At some places this is so deep embedded in the company culture that they created what I call the developer domain. A layer over the actual problem domain that is more complicated than the problem that the software is created to solve. No one but the creator can / want to work with this kind of software.

Why do developers do these things? I don’t want to think they do this to be able to get that hero status. In most cases I think they do it because it is fun. They want to write this impressive piece of code to show their colleagues. They do not enjoy the actual problem domain so they create their own.

Not so long ago I did this myself. I am ashamed to say that I had the “frameworks”.  In every technology I learned I found ways to create small frameworks with extra abstractions to make the solution more elegant. It was not elegant. It was overdesigned and expensive. I am glad that most of these things were my personal projects and no customer had to pay for it.

So where am I going with all this?

Over the last 20(30?) years not much have happened. We have created more tools that help us create complexity that we, or the customer, do not need.  A large  portion of the software written today could have been written with the tools we had 20 years ago. After all… a program is still just functions and data structures.

But there is a light in the darkness. There are champions out there that strive to make developers understand software can be simple and still perform advanced tasks. Others that are convinced that it is possible to create software with the same principles as other engineering branches. Watching lectures like Rich Hickeys “Simple made easy” and Juval Löwys “The Zen of Software Architecture” is inspiring. They make me feel that creating software is easy and fun.

Why not take inspiration from people in the industry that spend time to think  about the hard questions and create software loaded with customer value that your colleagues want to work with?


I  have lost count on how many times I have started to create a blog that in the end never went live. One problem was that I was actually creating the blog, not just the content. Starting with one based on the MS stack several years ago and now most recently one based on node.js and angular/react or whatever new shiny angle bracket thingy.

Another problem probably is that I was trying to do the same as everyone else. Creating a blog about pure technical subjects (“How do I do this and that”). Which is not my main interest.

A while back someone told me that people/developers rarely think. They read something, in a article, a blog or social media and just accept it. In social media we see this all the time.

The scary thing is… This happens in the software industry too. We get more and more Voodoo programmers. Programmers that find a solution on Google and accept it without thinking if it is a good solution or if it fits with the rest of the application. Some developers get very efficient in this and produce lots of code without knowing basic principles of software development.

When I started to think about this my brain hurt. Maybe I was one of them? Maybe I had been doing the same and accepting things without thinking about them? This combined with a gnawing feeling that there are several things that are wrong with the software industry lead me to believe that blogging about technical solutions is not the way to go.

I will probably be wrong sometimes, maybe often or most of the times. I can even accept being wrong all of the time if I can inspire more people to take a moment to think Before accepting a solution.