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?

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

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?

  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!

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!

Part time mad computer scientist, full time lover of the extraordinary.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store