Software design is hard and it can even be harder to discuss design decisions with other developers or to explain the reasons behind a decision. We tend to rely on experience and gut feeling but that's difficult to communicate.
Fortunately we are not the first ones facing these problems. For decades developers have reasoned about software design and some of them have condensed their thoughts into memorable principles, guidelines, and rules of thumb. You can read about them in countless books, articles, or blog posts. We all know principles like KISS, DRY, or SRP. But there are plenty of lesser known principles that are helpful nonetheless. Do you know the single choice principle (SCP), the law of leaky abstractions (LLA), or the principle of separate understandability (PSU)?
Almost every argument in a design discussion boils down to one of these principles. And our gut feeling and experience can often be explained with them, too. So we've created a set of cards with a selection of the most helpful principles or arguments to be used in a discussion about software design.
How to Use the Cards
One Card fits All
A simple but also powerful usage is to give a project a certain focus. For example if keepint the big picture in mind is very important for the current project, you could place one of the cards containing an abstract argument or even the back side saying "abstract" in a prominent place so you look at it very often. One card is enough? Why bother with the rest? Maybe there are some other reasons, too. ;)
Learning Software Design
Each argument card explains a single argument or principle. So instead of having to read dozens of books (although that might still be a good idea), you can learn the mentioned principles by studying our set of cards. We've worked hard to make them easy to read and understand. We also provide further content online.
Often a team consists of developers of varying experience levels. This makes discussions in a team uneven such that there are loud and fast-talking colleagues and others who are rather diffident or reserved. This results in the junior developers often not being able to grasp all the arguments of the fast-talking ones. And the more introvert developers, who also might have valuable input, even don't get heard.
When using the Design Cards in a discussion, each participant gets an own deck of cards (which is not necessarily the same for everyone). The key rule is that you can only play one card at a time. As a result you have to think about the most convincing argument to play out first. So the quality of the argument counts and not the quantity.
Background: Design Types
The Design Cards are based on the Design Types, a typology explaining developers' attitudes towards design decisions. Besides differences in cultural background, education, experience, etc. developers differ in four dimensions:
- simple-vs-powerful: Some developers prefer simple, straight-forward solutions and others prefer generic and powerful ones.
- abstract-vs-concrete: Some developers prefer taking the bird's eye view and others dive into all the little details.
- pragmatic-vs-idealistic: Some developers focus on time to market, others on long-term quality.
- robust-vs-technologic: Some developers prefer well-tried solutions while others like to make technological progress.
There is a questionnaire online at design-types.net where you can test yourself and your colleagues. It takes about 10 minutes, is free of charge and already more than 2600 people have taken part.
The arguments on the cards are also categorized based on these four dimensions as certain developers tend to use certain arguments frequently.
The Cards in Detail
Each argument card contains name and abbreviation of the principle as well as a short and a more detailed description. There are links to related principles, and an online version of the card with further information.
The 54 cards of set set will be divided into a basic and an advanced set (distinguished by a symbol on the bottom left). So you can start learning and using the cards with the basic set and add or exchange more cards step by step.
Sometimes just naming arguments for or against a solution is not enough. You can easily get on the wrong track or a discussion reaches a dead end. In those cases it is helpful to reflect the state of the discussion itself. Question cards help reflecting and action cards help resolving a discussion.
Focusing on all 54 cards at once can be quite unhandy even if you are familiar with all the cards. So you should build individual decks containing those 10–20 cards you want to use. Most likely you will have different decks for different circumstances, e.g. one deck for high-level architectural decisions and another one for code reviews.
What we've Done so Far
We already have...
- ...defined the contends of the cards (the basic set is already finished)
- ...build prototypes of the card sets
- ...evaluated the prototypes in several test groups
- ...looked for a print shop, distribution, regulations, financing, etc.
What we'll Do Now
Now we have to finish the contents of the rest of the cards and then we can have them printed and delivered.
What you Can Expect
We will produce a set of 54 cards from the basic and the advanced card set (argument cards, moderation cards, and manual) in a nice transparent plastic case, The pictures shown here are just mockups. The final product will be printed on high-quality cardboard, will have nicely rounded corners, the case will fit the dimensions properly, etc.
And we will continue with the topic. There will be more online content (more details on the principles, optional rules, etc.), and maybe even further card sets in the future.
Risks and challenges
The risk is really low.
Maybe creating the cards takes us a little longer than expected because we do this in our spare time. On the other hand we've been working together on similar projects for more than four years now. We know each other quite well and we know how to handle deadlines.
The print shop we chose is known for producing high-quality cards and even in the improbable case that we have to switch over to another producer, there are plenty of other possibilities.
In the end there might still be risks like the parcel service having an accident or the cards burning in an appartment fire—nothing really worth mentioning.
In short: We will produce the cards and you will get them. For sure.Learn about accountability on Kickstarter
- (41 days)