It’s sunny midday in the office, you’ve been called to a meeting. You and a bunch of other people enter the room. There is a whiteboard. You are about to be part of a system design session. With a kind of sick feeling in your stomach, you find yourself a place.
The company decided it needs to add an auction system, to increase its attractiveness to customers. Everybody starts talking, slowly at first. The one who knows the most lays out by the one who knows the most. Of course, he doesn’t know everything, he just repeats to you what he remembered, which may be false or at least not entirely true. In short, we need to provide auctions and bidding functionalities.
The AuctionX System Design Session
Then it starts. Somebody asks a question, then another, then answers start popping up, ideas fly, boxes and arrows are drawn, boxes are named. It’s like a storm, very loud and very quick. You tried to take part in those discussions, to ask some questions to raise an idea, but everybody just gravitated to the hottest topic: Since there are people involved in bidding should there be a graph database powering the solution?
The system design session ended. Dust settled. Everything is peachy, no problems, all boxes connected, all named. Everybody in the room now looks at you, they’ve done their work, now you JUST have to code it. It’s just a simple auction system. You get people bids, only paid bids count, you ship the winner the goods and refund losers. There’s an IAM, Notification Service, Payments, Billing and Shipping and Handling involved, you have all the pieces, now go!
The Problem
You look at the board covered with scribbles and after few seconds of tracing arrows you say to yourself, yeah that’s great but what the f*ck should I code? What the hell should I tell the team? How can we be sure we are building the right thing? How to be sure we all have a common understanding of what goes where and when? What system was actually designed?
I’ve been in this situation more than once, and I knew, there has to be a better way than relying on my poor memory. As always I started thinking and digging. Most of our problems have already been solved, at least partially. We just refuse to stand on the “shoulders of giants” so to speak. With that in mind I started asking questions: Is there any other area of software development that needs common understanding, and explicitness? What else needs to be self-contained, clearly defined, has to communicate, has to be designed, and then implemented?
Exactly: a Class.
The Olden Days
Is there a tool that helps to manage all of those things at the class level? Yes. Welcome back the CRC card!
Class Responsibility Collaboration Card is a tool used by programmers to create Object-Oriented Design. This is a fantastic (albeit bit aged) tool. It defines a concept, encapsulates it, list its responsibilities, define collaborators, and what is most important, it does that EXPLICITLY by creating a TANGIBLE artifact, which can then be updated/modified/removed. It also gives us the benefit of a common enemy.
How can this possibly help us? Ok, that is a different world, class is not a System nor it’s a component. No, it’s not, that is why…
Meet Our Savior
Hello I’m SRC card. System Responsibility Collaboration card.
System
This is basically the name of the system. In very early exploratory stages I recommend using surrogate names, why? You can read about it in “7 Fatal Mistakes Of Naming”.
Responsibility
This is the heart of our design session. What are the responsibilities of this system? What should it manage?
Collaborators
This is the next stuff necessary for our designs to be complete. In this section, we list with whom we need to collaborate to do the stuff that we need to do.
System Design Using SRC Card
You explicitly name, and define, all parties that are part of your system design. In case of our auction system let’s call it “AuctionX” they would be:
Why Should I Use It In System Design?
Because now it’s tangible. Now you and everyone else in the room has a chance to see this system in the same way. Now you should do a design walkthrough. Now you have an actual thing that you can take back to your team, not relying on our memory, and do some crunching with them. And find issues or design smells. There is at least one design smell around refunding losers, can you find what it is? 😉 -> Let us know!
You can download a sample card here, and use it right now. If you do not get all the details and where it can actually help you, stay calm. There are a lot more details and examples to come 🙂 I’m sure you still have many questions, how to use, where to use, what to look out for. I’ll gladly answer all of them in the next posts! Stay tuned!
Summary
As most of the time, a problem already has a solution, if not directly then at least one that we can reuse and adapt. Use SRC cards to manage complexity, and nail your system design sessions. Give a structure to yours and others’ thoughts. You will make the session much more beneficial. This is a great tool and I’ll show you how to make the most of it in the next posts.
If you like it, please share and subscribe to my newsletter, lots of cool stuff will be available only there, if you have any questions let me know 🙂