I'm writing this while sweating my pants off during a heatwave in Frankfurt am Main (FFM) in Germany.
It feels like there is no pleasant summer temperature anymore.
Either it's rainy, windy and cold, or we're in the middle of a heatwave.
Both hinder me from enjoying time outside.
Climate change is a thing.
Anyhow, let's get started.
This time, we're examining several software engineering practices.
Since this is what I do for a living, I can fill books here.
However, I have a couple of references I want to share with you today.
A small collection of posts I picked up in the past and still remember, because they aligned with my learnings working in the field.
It might seem natural in development to abstract things.
But from an operational perspective, especially in complex systems (which many merge into), greppability is more critical than not repeating yourself (DRY).
Let's elaborate on that a bit.
From a development perspective, people favour flexibility by encapsulating components.
It promotes separation of concerns.
They create variables and use them later on.
It helps to simplify things, reuse components and avoid errors.
They construct things like names, keys, URLs, etc., which enable changing values only in one place.
But, from an operational perspective, it all looks very different!
Dealing with much unfamiliar code, I find myself constantly searching inside the codebase.
I'm looking for path URLs, error messages, function names, and other relevant details.
This is especially hard when these are constructed from various variables.
This behaviour even led to production incidents at work:
Someone deletes some code because it appears to be unused, as determined by grepping the codebase.
To find out afterwards that there is a hidden usage somewhere, weirdly constructed from variables.
But what about typing? In a distributed systems world, you often don't have that. Grepping is your only option.
This article brings this concept to the point, and it discovered some essentials to look out for:
I found a piece where someone shares his insights after working for decades in the tech field.
I want to share it because it holds many lessons I have learned myself.
Let's go through them.
I wrote about my journey learning how product development works.
Collaborating with engineers in my daily business, I see that not everyone shares this understanding or is interested in it.
Due to this phenomenon – developers building products they know nothing about – I find the learnings within this article quite familiar.
The article even starts with: Almost everyone I know in tech does not think of tech the way that I do.
Nailed it.
Here are the highlights:
There is a difference between thinking you understand your customer‘s needs and actually knowing that the customer has that need.
If you cannot clearly identify a customer need, then you cannot define the solution that you need to create to meet that need, and you shouldn’t start anything until you do.
Principle: Meet the need as simply as possible. Understand and meet the need and only the need.
Principle: Use the shortcuts Luke! Your solution is about how to meet the Need you have identified.
Your solution is not about how clever you are as a programmer. Your solution should not be about ensuring that you keep your job by making it impossible for others to understand what you have built…
Do not build things yourself that other people have built and are cost-effective to use.
Next, we're in the development versus maintenance area.
I have seen both worlds and done a fair share myself. I developed and shipped products from scratch, operated 24/7 products for millions of people, and untangled legacy code.
Hence, my previous section in this newsletter was about the importance of greppability in operations.
This is why the section about maintainability is essential:
Principle: Build to maintain because maintenance is far far more painful than initial build
What almost nobody is good at is understanding the level of maintenance required for the solution once built.
Reducing maintenance time is a fundamental good in every single project, and if you can prove that increasing the amount of initial build time is very likely to achieve a reduction in maintenance then longer builds are a reasonable price to pay.
If the new solution is easier to maintain, because it was built to be maintained more easily, then the conversation changes and the risk changes.
Principle: Understand how the solution can be retired and/or replaced
One of the reasons I think that people who do not understand technology struggle to understand the costs of technology is because, as an industry we are very bad at knowing when to replace a solution.
Identifying when to replace a solution should be regularly considered and should have some accompanying metrics.
A team with the best intentions cannot maintain a solution forever, whatever that solution is.
And last but not least, people are humans, not resources!
I believe it is vital that everyone respects that and invests in healthy relationships among coworkers:
Principle: Teams are people not resources
I had a principle as a startup CTO which was that my team only needed to do 6 good hours in a day, and it was up to them when they finished. It was informal and not a “hard and fast rule”, but it was important. If someone felt they’d done good work, and wanted to go home early, then they absolutely could. That startup produced some of the most effective and efficient people I’ve ever worked with in tech. It wasn’t perfect, because nothing ever is, but I like to think that people were happy there. I’d far rather have that, than a lot of people stressed about hitting a deadline. It was a better attitude than most companies I’ve worked in (I may be delusional here too!) and the team was not put under pressure by me. We still delivered what we needed and often well before it was needed.
Look after people, and they will look after you and the company. It’s not a family, it’s a job, so treat people with respect.
I am very willing to accept that I don’t know everything, but I am not going to accept that people can’t do things because they aren’t used to them. People can learn things, and adapt. There is nothing that says that the way we used to do it in the tech industry is always “right”.
The personal blog from Uwe Friedrichsen is a must-read.
I really appreciate his perspective and the way he conveys it.
Today, I brought two special ones I highly suggest you pick up: The evolution of markets and Forget efficiency.
Let's explore them.
In this foundational article, he explains how the market changed over the years and how it affected the work within it.
He goes through the pre-industrial, industrial and post-industrial eras and each's core properties:
Market phases on the timeline by Uwe Friedrichsen
As interesting as he describes the pre-industrial markets, the central one I want to examine is the transition from the industrial to the post-industrial era.
For deeper insights, go to his article; it's really worth a read.
Here are the main highlights so that my thoughts afterwards make sense:
In an industrial market, demand is a lot higher than supply. As a result, sales are certain.
It is defined by the following properties:
High-volume markets
Low customization of goods
Supplier-driven
Low dynamics
In a post-industrial market, supply is a lot higher than demand. As a result, sales are uncertain.
It is defined by the following properties:
High-volume markets
High customization of goods
Consumer-driven
High dynamics
This differentiation is very, very important.
With this in mind, remember my earlier learning: "know what the need is" with product development driven by consumer needs?
Given that we operate in a post-industrial market, this approach is crucial.
Yet, so many companies and individuals (including myself more often than I would like to admit) are trapped in the industrial environment with the saying "just build it and they will come".
But that is not reality anymore.
It is also interesting to see which companies understood this, transitioned accordingly, and which, even today, remain stuck in industrial thinking.
Having worked within various industries, I've had the opportunity to observe multiple companies from the inside.
From my perspective, this ultimately comes down to market pressure.
When they're the top seller in a regulated industry, already owning a lot of contracts, life is good.
The future might not look that bright, but as long as the revenue is good today, there is rarely a need for real change.
It is that tipping point, when revenue is affected, and the foot really hurts. That's when companies actually go to work.
Sadly, this is often too late and causes bigger troubles than necessary.
But that's just the nature of human beings.
The article Forget Efficiency discusses how companies prioritise efficiency – optimising internal processes.
While efficiency is excellent in the industrial space, in the post-industrial world, it creates far more software than necessary, which ultimately becomes waste.
That is why it highlights a lack of effectiveness – searching for the right thing and doing only that.
I already shared quite a few learnings myself in my the efficiency trap article.
That's why I'll keep this section rather brief and suggest reading this article for further insights.
From all the way back, when Google+ was a thing, a Google employee wrote a manifest claiming that platforms are a thing.
Google+ was a social media network which failed.
The Google employee wrote this letter for internals only.
Due to the weirdness of Google+, he unintentionally posted it publicly.
We can actually thank Google+ for being able to read it.
Thanks to this phenomenon, he wrote it bluntly, directly, and in a funny way to read.
Please note that this was written many years ago; since then, a lot has changed. Therefore, read it more as an entertaining history lesson.
Looking at the content itself, it perfectly sums up the power of platforms.
The oft-quoted letter by Bezos from the early years, shifting the company to a platform-first approach:
So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.
His Big Mandate went something along these lines:
All teams will henceforth expose their data and functionality through service interfaces.
Teams must communicate with each other through these interfaces.
There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
Anyone who doesn't do this will be fired.
Thank you; have a nice day!
Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.
Number 7 is a good one.
I don’t care whether it’s true or not.
I just had a good laugh about the last part.
At the end, he went about his learning about platforms:
The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be ten times as much work as just doing it correctly up front. You can't cheat. You can't have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.
A colleague shared "the simplicity curve" in a presentation.
I came, I saw, I loved it.
It's in German, and it seems that it took some refinement to get the proper wording.
I translated it into English for this newsletter.
Please apologise if the wording isn't as precise and fitting as the original.
Here it is:
The simplicity curve version 3 by Gunter Dueck
I suppose there's no need to explain.
Upon reading it, I immediately thought of several uses.
I observed my past experiences and checked where the solutions fitted on the curve.
I especially love the "stupidly simple: so simplistic" and "ingeniously simple".
It is truly mind-blowing when solutions serve many people and rely on simple foundations.
That's the real genius.
Everyone is blown away by asking how that could ever work, and yet it works and has worked for so long, proving it every day.
These cases are truly revolutions.
You need an example?
Sure, how about computer science?
Everything operates on zero and one.
It all comes down to that.
It's crazy how you can use this small foundation and change the way everyone behaves.
As far as I got it, this concept is from the book "swarm stupid – We're only this stupid together." by Gunter Dueck.
I haven't read it, so I can't comment on it.
But, damn, just that title is a statement that gets my attention.
That's it for this one. I guess this was a longer one.
As I mentioned earlier, there is plenty to discuss in this space, and this is just a tiny collection.
I hope you've enjoyed the learning as much as I did.
See you soon. 👋
Any feedback? Drop me a line.
I value your feedback, so please keep it coming.
Feel free to send directly to this email ([email protected]) with any questions, comments, or feedback.
