The best thing you can do for your software engineering ecosystem is to add constraints.
What do I mean by constraints?
Anything that limits the degrees of freedom you have when building a software system. You might call them:
limitations restrictions standards contracts controls Regardless of what you call them, constraints will make your team better. Here are five reasons why:
#1: Constraints limit the number of decisions you have to make.
Our industry is possessed by a deadly cycle.
As we build software systems, we always run into complexity and problems. We see happier teams using a shiny new technology, and we run away to its greener pastures. Eventually, we discover the same complexity and problems that made us run away in the first place.
I’ve seen this cycle multiple times.
From Java, EJBs, and Spring to Ruby and Rails From Ruby and Rails to Node.
When you hear the word fall, you probably think of a downward motion.
Fall is almost always followed by down. Gravity, which causes objects to free fall, is intuitively understood as a downward force. Even our Fall season takes its name from the annual phenomenon of dead leaves falling down from trees.
Paradoxically, we can describe the journey of Deconstruction as falling upward. Falling Upward, by Richard Rohr, provided a framework for understanding my deconstruction journey.
NOTE (2023-04-19): I honestly don’t recognize the person who wrote this essay, and this was written less than two years ago. I think I must have a hidden inner suceptibility to cultic religious groups/movements when I don’t first recognize them as such. Because this is literally me preaching the Gospel of Ship 30 for 30. Ewwww.
About a month ago, I decided to give myself a firm kick in the ass to get back into writing.
If you’ve been a software engineer for very long, you’ve probably worked on a codebase that’s seen better days.
It’s not clear where the next feature should be added. Some components do too much, and some components do too little. Every change you make seems to break something else. Writing software has transformed from delight to drudgery. Your task list has become a toil list.
But it doesn’t have to be this way.
Do you really understand single points of failure?
A Single Point of Failure (SPOF) will cause an entire system to fail, even if it’s the only broken component. The Power of Multiplying By Zero is a mental model we can use to better understand SPOFs. Consider these two expressions:
865309 x 42 x 1984 x 221 x 0
865309 + 42 + 1984 + 221 + 0
Assuming you have beyond a third-grade education (or your country’s equivalent), the second expression may take you a moment, but the first expression should evaluate itself.
You’ve finally made it. You’ve been promoted to Enterprise Architect.
For many, this is the pinnacle of their career. For most, they arrive in their new role with an existential question:
What do I do? Nearly every organization that’s been around longer than FAANG companies is engaged in some form of software architecture modernization initiative. Over the course of my 21-year career, I’ve been privileged to work with dozens of them.
Builders run into problems. If there’s anything a product team should be good at, it’s solving them!
But most of us rarely spend time sharpening our problem-solving saw.
Enter the concept of mental models. Models give us abstractions of how one or more things actually work. They help us understand the world. George MacGill provides this analogy:
If your consciousness is the operating system, mental models are like apps, which you can use to help make decisions in whatever situations you find yourself in.
I did not want to write today. I still don’t.
Today is supposed to be a perfect day. A “Perfect 10.” The tenth consecutive day that I’ve published as part of Ship 30 for 30.
It’s been a stressful few weeks: I found out I had 90 days to move out of a rental house I had no intention of leaving any time soon. It’s a seller’s market, and buying a house right now feels like the closest thing to a “living hell” I’ve experienced in a while.
As I began my deconstruction journey, I started asking a lot of questions. I had so many that I organized them with a Trello board. As I studied the board, one of the questions leaped from the screen:
Is the Bible inerrant and infallible? Preachers and teachers had answered “YES!!!” my entire life. But for a brief summer encounter with wonderful people who practiced what the same preachers and teachers called “demonic religions,” it was difficult to hear anything else.