Point of view*

Introduction

Christmas is always a period of retrospecting. So let’s retrospect software design and development. When it’s time to design a new software system, a lot of variables must be taken under consideration. One variable is the past also. In order to paint the future, you have to look what you or others did in the past, but also what didn’t happen and why. Especially the what didn’t happen part might give you more insights.

If you take a step back, and look at similar to yours products and services, you will understand more the progress that has taken place in the domain, the growth, the risks and the failures, if they exist. The software analysis, design, and development processes, principles and tools have changed a lot in the past fifty to seventy years. But one thing is still the same. And this is people’s point of view to the goal, no matter if they are the stakeholders, the developers, the users. And the goal is to be better, faster, stronger, more successful than the competitor and keep or increase the power and domination.

Could the goal be different? Well individually yes, but in a corporate world the aforementioned explanation of the goal, is what you will hear from most of the companies, unless companies have become socialistic structures and I don’t know about it!

*Fates Warning – Point Of View (OFFICIAL VIDEO) – YouTube

Taking a step back

It’s not just about inserting any technology into a domain, there has always been a larger and greater shift, and this shift is how we face the challenge and what we actually want to achieve. The CEOs, the boards, the shareholders want revenue, to extend the clientele and sell more in general, the developers want(?) to build systems of quality, and the users applications that satisfy their needs.

But after all those years, we are still discussing about failed projects, or to be more precise, software projects full of bugs, expired deadlines, abstract requirements, unrealistic expectations, developers burnouts, toxic management and teams and the story goes on. But let’s take a trip to the past, and especially to the dark period of WWII.

Wernher Magnus Maximilian Freiherr von Braun (23 March 1912 – 16 June 1977) was a German aerospace engineer. He was the leading figure in the development of rocket technology in Nazi Germany and a pioneer of rocket and space technology in the United States after the war ended. von Braun worked in Nazi Germany’s rocket development program. He helped design and develop the V-2 rocket. Putting aside its purpose and the impact on people’s lives as an instrument of death by the Nazis, it was decades ahead of the rest of the world in terms of technology development and Wernher von Braun initial goal was to send men to the moon with it.

After the war, he was secretly moved to the United States, along with about 1600 other German scientists, engineers, and technicians, as part of Operation Paperclip. von Braun helped the Americans to build Mercury-Redstone rocket, then the Apollo program. United States spent 28 billion dollars to land men on the Moon between 1960 and 1973, or approximately 283 billion dollars after inflation adjustment. Spending peaked in 1966, three years before the first Moon landing. An average launch would cost about 1.5 billion dollars to launch 27.500 kg, after inflation adjustments. This is almost 54.500 dollars/kg. Between 1970 and 2000, the cost to launch a kilogram to space remained fairly steady, with an average of 18.500 dollars/kg. So this means that by iterating the V-2 rocket design, the launch cost has been decreased to one third. Later we will talk about SpaceX approach, but bare with me first.

Iterations in the software industry

We have been doing the exact same thing in the software industry. We have keep iterating and improving existing processes and tools. But while the tools were becoming better, more automation added to the development process, at the same time software system’s complexity was growing, competition too, deadlines got shorter, companies tried to keep the cost low in order to be competitive. But not changing our point of view to the goal is what led us to failures. It made us more short sighted.

One of the boldest examples is the agile methodology. I strongly believe that agile, as it is applied today by many companies generates more issues than it solves. The main reason is not the process itself, but the people who execute it. You can’t use a new process without changing your mentality, your principles, even your company’s structure. Agile is based on letting go, on trust, not on power and authority. A five hundred company people for example, that is still attach to a traditional management model will not transform from one day to another, but they will sell the whole agile thing. So instead of saving money and building highly productive teams, they produce the opposite results. Another thing with agile is that everyone can become a scrum master. Anyone can have a training and a badge, but do they actually have the mentality to play the scrum master role correctly, or they just repeat whatever is in the books? What is the silver line between the people who actually have the gifts and those who don’t?

Another revolution, is microservices accompanied with docker containers and kubernetes. Unfortunately microservices pattern has been misused or overused. You can’t even imagine what kind of bullshit I have heard all those years. I don’t blame the pattern. I blame the people who embrace every new toy without any seconds thoughts, because they are afraid that their company will be considered outdated. And it’s more. Some they refactored existing stable software system in order to deploy them as containers, while there was no reason for that. Not all of those endeavors were successful. Whenever you meet with as software house and in the slides decks you see microservices and try to sell it to you as the golden chalice, run away! Microservices pattern might make a company sell more, but will make not the programmers better, nor will improve any other implementation factors in a magical way. It will actually magnify the existing problems and add some more.

The product is indeed built for the customers, but the analysis, development and testing process belongs to the engineers, and they must have the chance, the time and space to do their best and feel proud of their work. To feel that they are creative, productive and that with their everyday actions and decisions they add value to the process itself and in the product too. Every step matters, every step must add value, not just the final product itself.

First principles thinking, or back to square zero.

Let’s return back to the Apollo program case. SpaceX and Elon Mask came on space aviation stage. They decided not to iterate the V-2 design once more, but they followed a completely new path. Instead of buying an expensive millions of dollars cost rocket, Musk decided to start his own company, purchased cheap raw materials, 3d printed many parts, and build the rocket from zero, and 14 years by reusing the Falcon Heavy platform, SpaceX managed to minimize the cost to orbit down to about 2.720 dollars/kg!

What SpaceX did is called first principles thinking. First principles thinking, was initially used by the ancient Greek philosopher Aristotle (384–322 BC), is one of the best ways to reverse-engineer complicated problems and unleash creative possibility. A first principle is a basic assumption that cannot be deduced any further or the first basis from which a concept is known. The whole idea is to break down complicated problems into basic elements and then reassemble them from the ground up. Does it ring a bell with OOP and objects relationships, data structures, splitting epics, designing a simple architectural diagram that encapsulates complexity?

First principles thinking is a path that will give us the chance to redefine our way of work and our point view to the goal. I am not implying to throw away every tool, every methodology, every pattern we have, but at least to rearrange our way of thinking, how we will find the solution to the problems, if the solution are acceptable and how we will implement them based on our needs, and not the trends.

First principles thinking is an alternative way of saying “think like a scientist.” Don’t assume anything, and believe me when I say that a lot of people get bitter. Start with questions like, “What are we absolutely sure is true? What has been proven?“. It requires to dig deeper and deeper until you reach the foundational truths. Rene Descartes, embraced this approach with a method now called the “Cartesian Doubt” in which he would “systematically doubt everything he could possibly doubt until he was left with what he saw as purely indubitable truths.”. There is not need to simplify every problem to the atomic level to get the benefits of first principles thinking, but to dive one or two levels deeper than most people. I will present you an example I found online.

Imagine you have three objects:

• A motorboat with a skier behind it
• A military tank
• A bicycle

Now, let’s break these items down into their constituent parts:

• Motorboat: motor, the hull of a boat, and a pair of skis.
• Tank: metal treads, steel armor plates, and a gun.
• Bicycle: handlebars, wheels, gears, and a seat.

What can you create from these individual parts? One option is to make a snowmobile by combining the handlebars and seat from the bike, the metal treads from the tank, and the motor and skis from the boat.

It’s the same with software. We can go deep enough, to define the primary reusable parts and how we can combine them again and again in productive and alternative ways.

First principle thinking in software analysis and design?

I have some suggestions and I present them to you. About all those issues I will write articles during next year, but till then I give you some heads up.

• Architecture decision records here
• Class Responsibility Collaborator (CRC) here
• Writing Effective Use Cases Alistair Cockburn here
• Writing Good Requirements here
• Stairway pattern here
• Zero/one/many testing pattern here
• xUnit Patterns here
• Integration test patterns here
• Object-oriented metrics by Robert Martin here
• Scrum patterns here
• Communication culture of (distributed) teams [pdf file]

Epilogue

Merry Christmas, and a happy new year! Be safe, take care of yourself and the people you love, and get vaccinated! Next year we will focus on more technical articles, there is a series for me to finish too!