I came across these 8 key lessons on the Art of Less from the Japanese Ink and Wash painting technique Sumi-e. When I read them, I couldn’t help but think about their applicaton to reusable software. Here are some initial thoughts (Sumi-e lessons in bold):
1. More can be expressed with less– One effective way to add value with reusable assets is to enable developers to be more productive. With less code, can they implement business functionality faster? can they reuse their knowledge of one asset when using another?
2. Never use more (color) when less will do: only support known variations. Needless flexibility not only increases development time, it also adds complexity and results in speculative design.
3. Omit useless details to expose the essence: what are the key interfaces that developers need to know about? If there are obscure configuration options or edge use-cases that most developers don’t care about – do they have to be communicated in an all-or-nothing fashion? When in doubt enable developers to peel away at your asset on a need-to basis.
4. Careful use of light-dark is important for creating clarity and contrast: There is a reason why your API was created and why it abstracts away certain details while exposing others. It is important to communicate the intent behind your design keeping in mind the developer’s need to get productive quickly.
5. Use color with a clear purpose and informed intention. Reusable assets should be part of a whole. Think constantly about how one asset relates to another and how a combination of them can make it easier for new automation opportunities. The key concept is to break it down into domain-relevant concepts that are part of a larger story. The colors do paint a picture, don’t they?
6. Clear contrast, visual suggestion, and subtlety can exist harmoniously in one composition. You don’t want every reusable asset to support completely different idioms – can you make it impossible for errors? can you provide warnings with actionable, informational messages for the developer? Think about suggesting good practices to the developer while they are inside a development environment.
7. In all things: balance, clarity, harmony, simplicity. As far as possible, reusable assets should be simple to setup and use. Strive for providing flexibility but follow the 80/20 rule – what do most developers want from an asset? Support those objectives and make it very obvious to achieve.
8. What looks easy is hard (but worth it). Reusable assets should make hard things possible – making it easy should be a goal to aspire to as always without taking the route of hiding too much information. Goal is to avoid repetitive code and configuration across multiple projects. It is extremely hard but well worth it!
What do you think? Do these principles resonate with you as a software professional?