Tech heroes are in it for the money

At the closing of the decade many tech writers take a step back and contemplate what it has brought us. Such as one of my favourite writers Steven Levy does in this, yet again, insightful Wired article. The main theme across these articles is that falling of the tech heroes. Or to be more precise, the tech startup heroes. Starting the decade with lofty promises of a ‘better world through startups’, they ended up defending themselves in court because it turned out they made the world a worse place. Surely they created valuable services, albeit most of them did nothing more than aggregating supply and make it somewhat easier accessible for the demand side, but it turned out the upside is greatly outweighed by the downside. We got excellent search but paid with our privacy, we got tons of news sources but they turned out to be untrustworthy, we got many free services but lost control of how and where we spend our attention. This list can go on for quite some time. And I think the root of this all is a misunderstanding about the fundamental motive of any company.
Although I am the first to cheer any effort to make our world a better place, I’ve also been quite skeptical of the deranged startup culture where ‘make the world a better place’ was nothing more than a checkbox on a list meant for luring investors. The web is littered with startups offering simple consumer products or services that do nothing for the world at large. Au contraire. But still that is what is on their front page. It is a red herring and the root to the downfall of the tech startup hero. In the end companies have to make money to survive. Despite all the other goals it might have, once this goal is endangered all other goals fly out of the window without a second thought. Every action within a company is therefore mainly aimed at maximising profit. While companies have the winds in their back they have the means to obscure this fact, but once the tide turns and the wind and rain is in their face the truth will surface. And I am not saying it is an ugly truth, but covering it up with a misleading message is kinda ugly. Looking at Zuckerberg testifying before congress you can see the crack appear in realtime. And his company is just the highest tree in a forest of wannatrees.
Tech startups are not companies with magic powers for solving world problems that takes a lot more than just tech, cola & pizza’s, and a can-do attitude. Technology can be an amazing enabler of progress, but it never acts in a vacuum. For the coming decade I plea for a bit more realism. And for every non-tech organisation to jump off of the tech-hero bandwagon and stop misusing words like ‘hackathon, nerd, startup, AI, blockchain, …’ to make themselves look cool. You should not pretend to be what you are not. Just look at the current state of the tech startup industry why not.

Importance of small teams

Software is complex. The complexity of many common information systems is way beyond that of any physical system. Operating systems, search engines, automotive systems, missile guidance systems, navigation systems, game engines,…and I can go on ad infinitum. And the list is growing rapidly since ‘software is eating the world’. This is problematic since the number of humans it takes to develop, expand and maintain an information system grows exponentially with its complexity. Sooner or later we will run out of humans. Another unfortunate consequence is that an increase in humans increases the likelihood of errors. In my experience exponentially as well, but I can’t back that up with hard numbers. This deserves a separate post, though, so I will skip it for now. The logical conclusion is that if we want more, more sophisticated, safer, and more reliable information systems we should keep the number required developers as low as possible. In my opinion the efficiency of a software team increases up to 10. Beyond that scale every other member has less added value for the end product. Most experience software professionals have in some point in their career worked for a large cooperation and wondered how they even managed to make any money. A counter argument could be that this is impossible for domains and processes that are inherently complex. I think there are two ways to attack that problem. First of all you should split up complex systems into separate domains and develop information systems for each domain. And split up the organisation along the same lines. Secondly I am convinced that the introduction of the next abstraction level in information system development will enable smaller teams to build complex information systems. The top-down approach mentioned in previous posts is a great contender in my humble opinion, but there are likely others. We should work on methods and tools that enable smaller teams for developing information systems.


In a recent talk by John Ousterhout called "A Philosophy of Software Design" he asked the audience what they thought was the most important concept in the history of computer science. It was the answer from Donald Knuth he quoted that struck a chord with me. Knuth answered, "layers". It took me a while but over the past years I came to realise that the concept of layers of abstraction has been one of the, of not the, most successful concepts in computer science. By abstracting hardware by machine code by assembly by imperative languages by OO languages, we were able to build information systems of truly mind-boggling complexity. It enables developers to stay within one abstraction level while designing and implementing an information system. Since lower levels were abstracted away developers had more brain cycles to spend on the abstraction level of their choice. It is the job of a compiler to turn higher level into lower level expressions. Although compilers will never be able to catch every error a developer introduces, their use will prevent the vast majority of mistakes they would have made if they had to write the lower levels by hand as well. There are a number of interesting things to note about this idea of layers.
First of all the it seems that we have been stuck at the current abstraction level way too long. Despite efforts such as 5G languages we got stuck at the OO-level since the early nineties. As people like Uncle Bob mentioned, it seems as if we got distracted by the internet and forgot to continue the great work our predecessors did in building all the abstraction layers we came to take for granted. Now that we realise that OO has its serious shortcomings as well, it seems we are kind of clueless where to go next. The most promising area I see is the domain of executable  business process (see for instance Zeebe). Despite the fact that these efforts have been met with a certain dedain from part of the software community. The most important difference with previous abstraction levels is that this approach starts top-down instead of the regular bottom-up. This could very well be the only way to get us out of the current impasse.
Secondly I have noticed that the mixing of abstraction levels is one of the biggest reasons for confusion in any discussion involving software technology. And they often get mixed since people feel comfortable at a certain abstraction level and will, often unconsciously, direct the conversation to that level. Discuss a technical business challenge with a DevOp and you will be talking about Kubernetes, Terraoform and AWS VPC's in no-time. Convincing similar examples the other way around can be thought up just as easily. Realising this I have found that the best professionals in our trade are the ones who feel comfortable at every level of abstraction. From high level business and even philosophical topics to low level technical details. Professionals that can go up and down the stack without losing oversight or getting stuck in one abstraction level while debating certain aspects.

A third interesting aspect is what I think will be the most surprising revolution in the way we build information systems: AI as the compiler. I have written extensively about how I think AI is destined to become the compiler between the highest abstraction level and the highest implementation abstraction level. You can read about it elsewhere, but it is the notion that this is about  creating abstraction layers that make it relevant for this post. 

Thinking, designing and building with a clear notion of layers in your head is key to building efficient information systems. It is a lesson I found so important that I have based the name of my next company on it: Stekz.