Software Design Sessions

Years ago I had the pleasure of working with a very talented PhD Software Engineer, not that a PhD always means something but it did in this case. They were a truly inspirational tech leader. During my time with their team, I learned a couple valuable lessons about software design and architecture. That’s our topic for today, namely, Design Sessions. We’ll discuss what they are and how to conduct them with your team.

Here’s a simple definition:

Design session — a planning activity with your team to discuss how a given feature should be implemented ending with a plan for execution.

Why should we care about design sessions?

Software design is the wild wild west. There are many ways to build software. There are many opinions. There are many unknowns. Let’s illustrate this with a simple story — Joe is tasked with implementing a new feature. Joe has two tasks, not just one. He has the job of actually delivering the feature but also he has the job of designing how the feature will integrate and change the existing platform. Joe begins his work by focusing on delivering the feature. When he does this the platform changes become a byproduct of his implementation of the feature. Before long a fork is created in the source code and the platform begins to deteriorate.

What Joe accidentally neglected to understand was how his feature fits into the whole. It wasn’t his fault per se, it was a byproduct of starting off on the wrong foot.

A better approach is to start with asking how the feature will be added to the existing platform. This question is better answered by the team. The team holds the “mental model” better than any one individual. There needs to be a shared understanding of the system. Without a shared understanding, we have a bunch of ants marching in different directions never returning home.

But I had some fear

So, by now, you are, hopefully intrigued. I, admittedly, did not like designing systems in a team environment at the beginning. This was because I felt my creativity would be restricted by others (by the very opinionated.) It turns out, the collective design skills of everyone are better than the skills of the individual. The whole team is greater than the team member. So, once I gave it a chance, I found the results were usually better, the implementation was smoother, and the shared understanding was a lifesaver because the team can have your back.

In the end, my creativity wasn’t hindered. If anything, it shown more brightly. Also, I learned from others. It’s real arrogance to think you know best. When other people disagree or back you, there is an additional level of confidence in what you are doing.

What is a design session anyway?

Here are the basic steps of a design session:

1. Priming —It beings with one point person for the feature. They do the homework, the prototyping, and gathering opinions on the design and possible approaches to the problem.
2. Discussing — A session is called and the team gathers. The point person presents the requirements and their initial take on viable approaches. The team discusses these various approaches and perhaps suggests alternatives.
3. Data Model — Starting from the data model the team discusses what data structure is needed. They take into consideration what existing data structures exist and how they might leverage them. Starting with the data model cannot be understated. Almost all architecture problems derive by doing poor data modeling.
4. Code Structure — Next, we look at how the code could be structured. Once again this is a team discussion. It usually flows quite naturally from the data model. By this point you should be seeing consensus.
5. Plan — At the end, everyone has a shared plan of attack even if they are not directly involved with the implementation. The implementors are now free to code with a plan in hand.

Why this approach rocks!

Now, I really love design sessions. They are beneficial to everyone. By doing them you raise the quality of the entire team. Less experienced developers will quickly get a “feel” for how to build scalable, maintainable, and clean software.

The implementors of the feature will find that much of the pain of their work gone. Now they merely need follow the plan. I cannot tell you how nice this is. In software development, the real bottlenecks are all the decisions that need to be made. When these decisions are made, you can just get your work done. It’s a great feeling. You don’t have to worry if you’re doing it wrong, if people will hate your work. You know they won’t.

Moreover, you can deliver quality features to your business, users, and fellow developers.

So, get out there and design together. Learn how to talk in terms of data modeling and code structure. You don’t need more than words and whiteboards. It’s small price to pay for great work.

Happy designing!