Early Decisions in Software Development

The Ripple Effect of Early Decisions in Software Development

I saw front-end developers just starting a prototype, which became the productive foundation for the next 10 years. Not in a positive way. I saw backend developers deciding on a tightly coupled monolith to get things done quickly.

And I see them trying to revert and correct their hidden strategic decisions of day one. What they had in common: They were unaware of making decisions as regular individual contributors or tech leads.

This isn’t what software engineers should do and has nothing to do with agile.

I was one of them, still haunted by those decisions 15 years ago.

The Hidden Power of First Moves

You're at the starting line, choices at your fingertips. These aren't just any choices; they're the first brushstrokes on your masterpiece. The seeds from which your entire project will grow. The right early decisions act like a compass, guiding your project through the wilderness of technological advancement. This is where the journey begins, and setting off in the right direction is crucial.

Engineer’s Credo – Why we should not be lazy

The following Credo, I set as a standard for myself the colleagues work with, and the employees I employ. It shall serve as my context for the following article.

As an engineer, I shall hold the public's safety, health, and welfare paramount and continuously learn to maintain my competence and practice with integrity, responsibility, and accountability. I commit to innovation, excellence, and sustainability, ensuring that my work contributes positively to society and the environment with the utmost respect for ethical standards and professional conduct.

My own Credo as a -State Certified Engineer-

The Problem: There is no “Let’s fix that later.”

A prime example is selecting technologies for a pipeline, a programming framework, or a software architecture. These decisions may seem small initially but tend to have the following aspects:

• long-lasting,

• hard-to-revert,

• and costly-to-substitute consequences.

👉 In other words, you will live with your decisions in one way or another.

Thinking twice about the tools and processes you introduce to your workflow, company, and teams is crucial. By investing time and resources into thorough planning early on, you can avoid costly and time-consuming changes down the line. This is especially important as companies grow and evolve, where poor initial decisions can lead to stagnation.

The notion of “We can always change later.”

It's one of the worst things I have ever heard. When you don’t have time to do it right, you likely won’t have time later. The idea behind that saying is that we will have money later and the resources to fix what we break today–which is most often a false notion.

👉 Maybe your company will have more budget and more developers. But, and this is important to understand now, those resources will be spent on new iterations and features, not on refactoring or reversions. No business likes the idea of building expensive things twice.

But Agile…

👉 Agile¹ has nothing to do with not thinking about your work and the outcome now, and it’s not about postponing responsibility.

Most problems I have mentioned happen in the early phases of a software product. The code base and infrastructure should be solid when making software architecture decisions.

We can iterate features later quickly and gather customers’ feedback continuously, as long as our foundation supports us in doing that.

🍪 So take special care in the first weeks and months; those count much more than you might think.

A/B Testing the foundation

Of course, you can play around with different architectural approaches, but an essential question you should ask yourself is when you start this testing.

❌ After 12 months of pushing feature by feature.

✅ Before you start to put things onto your foundation.

Gathering feedback in an agile way is possible before hitting the customer. Create prototypes of code bases and architectures, test how to deploy them, and how difficult it is to make changes. How can your team handle it, and does it help you meet your business goals long-term? Gather feedback for yourself as the first customer. Work towards a decision.

Decide proactively for 5-10 years. You must focus on business in those years, not fixing early laziness. This is your Responsibility as a Software Engineer.

Example: My honest opinion about the mandatory Monolith-First approach:

I read often to start with a monolith and move towards a microservice architecture later when needed. Just get things started, right?

👉 The reason for picking Monolith isn’t the better architecture; it’s simply treated as something you can handle initially.

Betting that you will have time and money later to fix it when it’s X times more complicated is gambling; not engineering. When your primary motive as a business is exactly that, go ahead. If you plan long-term, think twice.

😱 Every time I read about those “consultants" recommendations" like “Just don’t think about it, you can always change later,” I can’t help myself other than seeing a sustainable business approach…for the consultant.

We are Engineers. We need to have the general picture of what we will do in the next few years already in mind; otherwise, we will lay the wrong foundation!

Understand first, then decide.

Continuous Delivery and Early Decisions

CD, as described in Minimum Viable CD, comes close to non-negotiable for me. It’s most important for any commercial business to gather feedback as early as possible.

Continuous Delivery is an Engineering practice. It’s a perfect foundation for working in an agile way. Release quickly, get early feedback, and iterate on that.

Like the agile chapter, this doesn’t mean you can be lazy and postpone essential foundations. It’s vice-versa; Bad decisions will hinder you in the idea behind CD: Fast iterations and continuous feedback.

The Cost of Change: More Than Just Dollars

Change isn't just about the time or money it takes to implement; it's about the domino effect it triggers. Early decisions, like the architecture or technology stack, are the DNA of your project. Change one, and you might find yourself recalibrating the entire system. The cost isn't linear; it's exponential. Understanding this will help you appreciate the gravity of these early choices and encourage a more deliberate, thoughtful approach.

Early on, when laying the foundation as a software engineer, changes were still relatively cheap and quickly done. So why not just make it right in the first place?

During my years as CTO, Software Engineer, and Mentor, I faced a common problem: Lack of Understanding.

👉 It’s not about the time to make it right; it’s about not knowing how to make it right and not spending a decent amount of time finding out.

Cultivating a Deep Understanding

How do we make the right choices? It's about understanding your tools, your team, and the landscape:

• Know Your Tools: Dive deep into the capabilities and limitations of the technologies at your disposal.

• Understand Your Team: Gauge your developers' skills, experience, and learning curve.

• Read the Landscape: Keep abreast of industry trends, potential future requirements, and how they might impact your project.

• Understand the architecture and its long-term effects.

This deep understanding is about making informed decisions and fostering an environment where every choice is a step toward a more robust, adaptable future.

Steering Clear of the Gamble

Treat each decision not as a bet but as a calculated move in a chess game. Encourage your teams to weigh each choice with the seriousness it deserves. Teach them every decision is a building block in their project's foundation. The mindset of "we'll fix it later if it's wrong" doesn't hold up in the complex world of software development, where each component is intricately linked to many others.

Don’t make decisions just by yourself because you are an Engineer and don’t want to bother others with their valuable time. Work together with your peers and colleagues.

👉 Talk about the consequences. Understand that it’s not responsible if you don’t do that.

Embracing the Eternal Learner's Journey

To remain at the forefront, foster a culture of continuous learning:

• Seek Diverse Perspectives: Engage with ideas and viewpoints different from your own to broaden your understanding.

• Embrace Failure: View each setback as a learning opportunity and a step toward mastery.

• Stay Curious: Maintain an insatiable appetite for new knowledge and skills.

This continuous learning journey isn't just about keeping up with the latest technologies or methodologies. It's about cultivating a mindset where growth, adaptation, and foresight are integral to development.

Beyond the Code: Understanding the Business

As a Software Engineer, you make business decisions with the first key-stroke. Be aware of that, even as a Junior Engineer. Your work isn’t less important than others. You add something to a collection of things that will couple and become one.

Your added part will be interconnected with other contributions. Reverting later a poorly made decision, in the beginning, will cost a lot.

Thanks for reading; happy holidays! 🎄

Adrian

1. https://agilemanifesto.org/