Radical Simplicity Logo

Happier Developers with Radical Simplicity

Radical Simplicity is a movement in software development to refocus on the core of software development. It does away with all ceremonies around frameworks, and reduces the number of parts of a system to the essential ones. Not a dozen different databases, but one. Not a dozen programming languages, but one. Radical Simplicity takes away the writing of boilerplate and glue code for frameworks. Configuring different systems and making frameworks work was not what brought you into developing software.

But isn’t it like taking away your toys? Isn’t it another hype developed by business types to make developers more efficient, to drive developers more to get more out of them? So what is in for you as a developer?

The term “Radical Simplicity” for technology was coined by me to make development work more satisfying. I have been teaching myself coding in a department store as a kid around forty years ago to write video games and have been developing software ever since. Back then there were no complicated frameworks, no database systems or microservices. You wrote code in machine language with a ROM listing by your side, that was everything you needed to write excellent software. It took brains and creativity to come up with clever solutions to daunting problems. This is not to say we should go back to that time, but the 80s brought amazing software written by individual developers. Sophie Wilson created the ARM microcode by herself. David Braben wrote the game Elite. Dan Bricklin and Bob Frankston wrote VisiCalc in two months. These people wrote real code, not some glue code that connects existing frameworks.

And while it is a good thing to not invent everything on your own, and it is a good thing to therefore write some glue code, with too many frameworks, systems and microservices in the end glue code is the only thing you write.

With all these frameworks and programming languages and new databases, do you always want to solve the same problems over and over again? How to show and wire a form field? How to serialize JSON? How to write an object to the database? Or do you want to work on real things and get things done?

Writing only glue code is boring. It’s not something that is challenging or satisfying. So we tend to add more and more frameworks as a surrogate for real code. Learning more and more and always newer frameworks is a surrogate for writing satisfying code. It’s like sugar which creates a short high but then kicks you in the stomach. A new framework is fun for a short time but this quickly wears off when you have to find some edge cases in the API, some functionality that is not there or slightly different, when you need to upgrade the framework for a feature, and it breaks all your existing code. Then you want to get your new high from a new framework, leaving all the glue code, edge cases and broken upgrade behind you.

Radical simple applications have deep domains and a little code in frameworks
Radical simple applications have deep domains and a little code in frameworks

Another surrogate for meaning and creativity is writing your own database. Because of writing demeaning glue code all the time some developers start writing their own frameworks, their own database systems, reimplement the wheel for a hundredth time.

Free Video Consultation for CTOs and VPs of Engineering!

Have you thought about getting help with architecture as a CTO? If you're a CTO, VP Engineering or Head of Development I want to hear from you: Book a free video chat with Stephan to find out about CTO coaching or ask any questions you have. You want to learn more? Go to www.amazingcto.com. Or drop me an email at stephan@amazingcto.com or Signal ( +49 151 4248 1170 ). I am experienced CTO and have coachees all over the world, from developers that have recently been promoted to CTOs, from first time founders who are CTOs to experienced CTOs in startup.

But don’t you want to work with new shiny things? Everyone does, don’t they? And isn’t recruiting keyword driven. If I do not add new programming languages to my resume, am I still employable? How do I stay employable? First, good companies do not hire by keywords, but hire by skills and character. Only bad companies who need to recruit many developers for those leaving, are keyword driven and scan your resume for relevant keywords. There isn’t a big loss if they don’t want you. But I’m also interested in new things, I like new things, I like to explore new things. A company should help you with side projects, open source projects, prototypes and experiments to keep up to date to what our industry is currently doing. Because learning new things will stimulate your thinking and broaden your horizon, so you write better code with existing systems. My code got much better after writing lots of Haskell and Scala code - without the need to use this in a company product (well I did, and it was a mistake).

With a technology zoo it happened to me over and over again that I need to spend time on upgrading all those frameworks, libraries, systems and databases. This takes time, and you postpone it over and over again when you fear that it will break your systems until there is no way anymore to postpone the upgrade. Then you spend days or weeks on upgrading the frameworks and systems. And things break left and right and there are more and more things popping up that don’t work. Then dependencies of your dependencies no longer work because they are incompatible. And instead of writing challenging code you read about compatible versions and ways to get your dependencies work with each other. Having the absolute minimum of systems and frameworks reduces this unpleasant and unnecessary work to a minimum.

Do we really need new technologies all the time? Do we need them in our work? Do we only need them to boast to our peers online about the cool stuff we are using? Is it about being cool?

What I find cool - if we want to explore such a category - is not someone using the newest CSS framework but creating cool things. Like Sophie Wilson writing the ARM microcode. My proudest moments in coding are when I had created something new. As a kid I was fascinated with the Tower of Hanoi:

The Tower of Hanoi (also called The problem of Benares Temple[1] or Tower of Brahma or Lucas’ Tower[2] and sometimes pluralized as Towers, or simply pyramid puzzle[3]) is a mathematical game or puzzle consisting of three rods and a number of disks of various diameters, which can slide onto any rod. The puzzle begins with the disks stacked on one rod in order of decreasing size, the smallest at the top, thus approximating a conical shape. -Wikipedia

After I wrote a program on an Amstrad CPC with which I could play Tower if Hanoi, I figured out an algorithm by using coins on how to solve any starting position - without the help of the internet because it was ten years before the internet arrived in Germany. Watching the computer solve the problem on its own with my code was magical.

The same thing happened later. When working in an internet startup a customer wanted fulltext search. This was before open source SQL databases existed, before fulltext search as a system or library was easily available. So I’ve read scientific papers about fulltext search and reverse indices and implemented a search engine on my own. I felt good and proud about my cleverness solving a problem that looked daunting at first.

As developers, we want to write deep domain code, deep features. When you type “2+2” into Google, it doesn’t search for “2+2” but presents a calculator and prints “4”. Google corrects typos, and shows a corrected version, most other fulltext search engines don’t. This is a deep search box. When looking at search in companies I’ve worked for, it’s basically connecting to Lucene, Solr or Elastic. There is no deep coding writing search. It’s not about wowing the user, about creating a deep feature. Think Star Trek. The features we see are shallow, writing the least amount of code to connect to Elastic and have fulltext search, then move on to a new feature. Writing shallow features isn’t intellectually challenging and interesting.

So we move on to a new company and a new jobs, in search for fulfillment, purpose and sense. We hope to find this in new shiny frameworks and new programming languages, just to find out after some time that we again can’t get fulfillment. Rinse and repeat.

Instead of shallow domains and glue code developers need to work on deep problems to change the world. Glue code does not result in the biggest possible impact. As developers we need to write intelligent algorithms to user problems and not shallow form-frontend-to-database applications. We need to spend time on having impact instead of naval gazing and framework migrations. Just think of all the billions of hours lost in migrating from one framework or system to practically the same - but newer - framework. We could make the world a better place with our time spent, instead we run in circles.

To make this work, business and product managers need to focus on deep domains. And where they are not capable of doing so, developers need to help them think deep. We need to show them what deep features are and how to wow users with a “magical” product that solves their problems intelligently.

Writing deep code makes us consistently happy. Code that we can be proud of. Code that fulfills a purpose and has glowing fans. Sustainable happiness does not come from a sugar high of new frameworks, it comes from writing beautiful, astonishing, challenging and deep code.

Radical Simplicity is our first step towards that future.

About Stephan

As a CTO, Interim CTO, CTO Coach - and developer - Stephan has seen many technology departments in fast-growing startups. This is where the idea of Radical Simplicity comes from, because he has seen too many complex setups that costed money and had their problems. He taught himself coding in a department store around 1981 with VIC20 Basic and went on to write code - and was paid for many of them - in C64 BASIC, 6502 machine code, CPC BASIC, Z80 machine code, 68000 machine code, Amiga BASIC, GFA BASIC, Blitz Basic, QBasic, Turbo Pascal, Modula-2, Oberon, Delphi, C, C++, Lisp, Prolog, Perl, Python, Java, Javascript, Scala, Erlang, Haskell, TypeScript, Go and Rust amongst others - using VIC20s, Sinclairs, C64s, Sharp Pocketcomputers, CPCs, Amigas, Beboxes, Atari STs, MSDOS machines, Windows machines, Linux - pre distro - machines, SUNs, SGIs, NextCubes, and many Quadras|iMacs|MacCubes|MacBooks|MacBookPros|iMacPros. Stephan has founded several startups and worked in small and large companies as CTO. After he sold his latest startup he took up CTO coaching. You can find him on LinkedIn

Stephan also wrote a CTO Book

My CTO Book