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?

One thought on “The Developer Domain

  1. You really make it appear so easy with your presentation but I to find this topic to be actually
    one thing that I feel I might by no means
    understand. It seems too complex and extremely large for me.

    I am looking forward for your next post, I’ll try to get the cling of it!

Leave a Reply

Your email address will not be published. Required fields are marked *