2 Lessons from 20 Years of Building Software Platforms

2 Lessons from 20 Years of Building Software Platforms

Over the past two decades, I've had the chance to build some pretty complex, enterprise-grade software platforms that millions of users rely on daily. And if there's one thing I've learned along the way, it's this: always start with the interface layer.

Let me explain why this approach has consistently worked for me and why it could also be a game-changer for your projects.

1 / Start with the Interface Layer

I can't tell you how often I've been in meetings where the first question is, "How should we define our database?" or "What services should we build?" And every single time, I have to say, "Nope! Let's think about the UI first."

Here's the hard truth: no one really gives a damn about your services — whether you've got one monolith or hundreds of microservices — users just don't care. You should care, but not at this stage. What users do care about is the interface they'll be interacting with — the experience, the responsiveness, the performance.

So, start there. The backend and database should only exist to serve the user's experience—whether it's in real-time through the UI or as part of an async activity via a scheduled job or workflow. If the backend's purpose doesn't fulfill one of these two activities, you're most likely over-engineering.

Here's why starting with the interface layer is so crucial:

  • Clarity of Focus: When you begin with the UI, you're forced to think about the user's journey first. This clarity naturally narrows down what's important and keeps you from getting lost in technical details that don't add value to the user.
  • Avoiding Over-Engineering: I've seen teams spend weeks building elaborate backends that never get used. Focusing on the UI first keeps the backend lean, building only what's necessary to deliver a great user experience.
  • Quick Iteration: Defining the UI upfront allows you to prototype and iterate quickly. You can gather feedback early and make adjustments before you've invested too heavily in the backend. This approach saves time and keeps the team focused on delivering what users really need.
  • User-Driven Development: When the UI is your starting point, every backend decision is driven by how it will impact the user experience. This ensures that every service, data model, and infrastructure piece is aligned with delivering value to the user.

2 / Event Storming: Simplifying Complexity with Collaboration

Let's discuss Event Storming, a method that's changed the way I tackle complex systems. If you're unfamiliar with it, don't worry; I'll give you a quick rundown on how it works and how to get started.

What is Event Storming?

Event Storming is a collaborative technique used to map out the entire workflow of a system by focusing on events and commands. It's a simple, visual approach that involves everyone — from developers to business stakeholders — coming together to explore how the system should work.

How to do Event Storming?

  • Gather Your Team: Bring together everyone involved in the project, including developers, product managers, and business stakeholders. The diversity of perspectives is crucial for building a complete picture.
  • Start with Events: In Event Storming, an event is something that happens in the system. Start by identifying the key events in your system — things like "Order Placed," "Payment Processed," or "User Logged In." Write each event on a sticky note and place it on a wall or virtual board.
  • Define Commands and Actors: For each event, think about what commands trigger it and who (or what) is responsible. For example, the "Place Order" command might be triggered by a user interacting with the UI, while an automated system might handle the "Process Payment" command.
  • Map Out the Workflow: Arrange the events chronologically to map the system's workflow. As you do this, you'll likely identify gaps, dependencies, and opportunities for optimization. This visual map becomes the blueprint for your system.
  • Iterate and Refine: Event Storming is an iterative process. As you work through the sessions, the design becomes more refined, and your understanding of the system improves. This is where you start to break down the complexity into smaller, manageable pieces.

Why Event Storming Works?

  • Creating a Shared Vision: Event Storming brings everyone together to create a shared understanding of how the system should work. This alignment is crucial. It ensures everyone's on the same page and working towards the same goal.
  • Breaking Down Complexity: Large, complex projects can be overwhelming. But when you break them down into small, manageable events and commands, they become much easier to reason about, estimate, and implement. This approach turns a massive, daunting task into a series of smaller, predictable steps.
  • Visualizing the Big Picture: Event storming's visual nature helps everyone see the entire system at a glance. This is invaluable for spotting potential issues and identifying opportunities for optimization early on. It's like having a blueprint that guides the entire development process.
  • Iterative Refinement: Event Storming isn't a one-time thing. It's iterative. As you work through the process, the system design becomes more refined, and your estimates more accurate. This flexibility is key in adapting to changes and ensuring the project stays on track.

While I'm a big proponent of Event Storming, I'm not here to push Event Sourcing or CQRS architecture. That's a topic for another article. Frankly, many teams might not be ready for it, and for good reason — it requires experience and discipline and often brings architectural complexity that can be overkill for many projects.

Wrapping Up

Estimating and executing software projects doesn't have to be overwhelming. By starting at the interface layer, you keep the focus on what really matters: the user experience. Event Storming helps break down complexity and build consensus, making estimation more accurate and the development process smoother.

These techniques have served me well over my career, helping me deliver software platforms that have served millions of users. Give them a try — you might find they change how you approach your projects.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了