This is an online book / blog about something {undefined} in software. Software has a lot more to it other than code. It’s about engineering, practice, culture, people, architecture, psychology, economics, product and project management and yes, even a lot of philosophy. As they are all intertwined in one another, this book/blog is all about them.
I presume that reading 115 chapters is a very time consuming effort. So instead, I gathered what I see as the most monumental and important chapters written in the series of The Monk who Sold his Server. I hope it will be the most beneficial use of your precious time. Thank you for investing it into reading these.
Not Company Values
Velocity, Customer Experience and [in]Stability are all tied together, each one forming a relationship with the other. A relationship explored in The Philosophical Layer series. What’s for sure is that the three do not constitute company values. I had to learn that the hard way. Read more…
Scaling Strategies: Infrastructure or Applicative Scaling
When it comes to scaling our application and our Compute, it is an open question which should own it. Should we increase our application’s throughput and concurrency by coding and extending it? Or should it be left to our underlying infrastructure?
Ego Driven Development: The Dark Side of Ownership
This article is the only one written with leadership and management in mind. Many years ago I was fired due to a company shutdown, just before I deployed my masterpiece to production. During the first Covid lockdown of March 2020, I found my self deeply reflecting my career. Ending up realizing my code was never mine to begin with. Neither is yours.
Non Recyclable Waste: Inefficiencies
The series of Wasteful Applicative Evolution revolves around time waste. But what is time waste itself, what is inefficiency? How do we measure it and what good will it being to remove it? Understanding the concept of Inefficiencies is a building block to running and managing any R&D operation. Read more…
Avoidance: Eventualism & Evolution
Every application goes through erosive processes, leading a demise or decay when left unattended or incorrectly attended. It is The Inevitable. The fuel of these processes is the work itself done, the Change itself. With Eventualism in mind, we can see all we can do is postpone or slow those down. Once we realize it, It would lead us to a whole new set of solutions for this very problem. Read more…
Spring of Change: The Development Lifecycle
Through the entire series of Change Driven Design, we are modeling the entire reality in an Event Driven way of a single generalized Event named Change. Each one is preceded by a Cause, originating from a Source. Once modeled as such, we can better analyze and design our applications. A misalignment with it might be a source of Inefficiency. Read more…
Fragments of Change: Architecture of Products and Organizations
Product-driven Changes are nothing like Technical-driven ones. It may lead to a misalignment between how our applications are designed and how are products and companies are built. Which is another source of Inefficiency. Read more…
Product of Change: Behavioral Applications
Actually, what are Products any how? Products are built out of Flows/User Journey.. and also built out of other Products. This distinction differs Technical-driven applications from Behavioural-driven ones, and those might have to be modeled differently.
Monolithic Pressure: Throughput meets Design
In the series of Breaking Change, we have established another source of Inefficiency, a Bottleneck in the development workflow itself. Our team of engineers have a Throughput, a rate of Change. It is applied to an application, meeting its design. This cross-road is what causing applications to grow fast and potentially incorrectly. The reason behind how dreadful Monoliths are coming to this world. Read more…
Paying Penalties: Non-Beneficial Applicative Splits
Incorrectly splitting applications to Services or Microservices is another source of Inefficiency. We’ll be reviewing some use cases or splits done wrong, and how they effect our development workflow leading to Inefficiencies in it. Through it, we can come up with better design principles for distributed applications. Read more…
Macro, Nano, Micro-Services: Does Size Matter?
An application size is impermanent. It continuously grows bigger, as more Change is applied to it. It can also grow smaller when refactored. If that is so, is it wrong to split our applications according to their sizes? In this controversial chapter, we’ll see where did this size criteria came from and whether there is a better one to design according to. Read more…
Expectations: A Customer-Driven Architecture
In the series of Future Changes, we are exploring the process of architecting itself. One of the most important parts of it, is to realize what it is for. And it is for our customers, who have some very interesting expectations out it. Only one of which is consistency, an important trait on its own. Read more…
Storage of Truth: Persisting Events
The system architecture we came up with in the Future Changes series is a mixture of Enterprise Messaging Architecture, the Reactive Manifesto and Event Driven Development. In it’s heart is a message called {EVENT} which describes Actions performed by our applications. It opens up not the question of not only what is the Source of Truth, but what the truth really is. Read more…
The Done Undone
In the opening chapter of Projection, a book about product and project management, we dive into a very deep sense of ours.. that the work never ends. If you even wondered why, it is because every Change entails Feedback, and every Feedback entails Change. And this realization has a deep impact on our work, and how we manage our work. Read more…
Gut Feeling Driven Development
Feedback is critical. Without it, we’d find ourselves in the wrong rabbit hole. But there’s more to it. Because we can also gather insufficient Feedback, incorrect Feedback, the wrong Feedback and at the wrong time. And it has some dire consequences. Read more…
The Yin & Yang Iteration
Tension between Product and R&D is something known and experienced worldwide. But it is manageable and preventable, once we realize that both product managers and engineers are a part of a process known as Creation. Read more…
Actionable Plan
Lean and Agile are fantastic. But down to earth, Sprint planning is a hard process. It is really hard to come up with a viable plan for the next week or two. But it is possible, once we better understand what kind of Tasks we have and what kind of Uncertainties we are about to face. Read more…
Deviating from the Path
If planning one Sprint is hard, planning a Roadmap for years to come.. it’s a whole other story. Because, as John Lennon once said, life is what happens when you’re busy making other plans. So, in order to know how to plan Roadmaps, first we need to dive into the reality they are living in. As once we have a Roadmap, we start deviating from it all the time. Read more…