The application of clarity and simplicity principles to a product's user interface and experience, rather than to its underlying code. Rolf observed that the most successful products tend to share uncluttered, intuitive interfaces that make their purpose immediately apparent. Just as clean code prioritises readability for developers, clean design prioritises comprehension for users. The two share the same underlying mindset: don't accept halfway results, and always optimise for the person who has to work with what you have made.
"If you have a product, you see the most successful products are the one with clean design. So you have don't have clean code, but clean design. If you have something cluttered in, for example, on a mobile app, you have something that's just complicated. Those apps don't usually succeed."..."And that's kind of the same thinking process. What that you put your understanding and the usability on first place and don't accept halfway results, but always try to make it better. And that's something what you do with clean code as well. It's the same mindset, I would say." — Rolf Kunisch
The principle that any given piece of knowledge or business logic should exist in exactly one place in a system, so that changes propagate consistently without the risk of contradiction. Rolf used a value-added tax example: extracting the tax calculation into one named method means legislation changes require an update in one location only. Simon noted this connects to a quote from Robert C. Martin: "Truth can only be found in one place: the code." A system with a single point of truth for its logic is easier to maintain, test, and reason about.
A humorous backronym used to describe code that violates the DRY principle by duplicating logic or knowledge in multiple places. The term was coined as a contrast to DRY and is sometimes expanded as "Write Every Time" or "We Enjoy Typing."Â During this episode it was independently coined live in the chat: "You want DRY feet, not WET feet." WET code is harder to maintain because a single change in business logic must be tracked down and repeated in every location where it appears.
A coding principle stating that every piece of knowledge should have a single, authoritative representation in a system. When logic is duplicated across a codebase, any change must be made in multiple places, increasing the risk of inconsistency and bugs. Illustrated this with a value-added tax example: rather than scattering a raw multiplier throughout the code, extracting it into a named method means the logic lives in one place and can be updated once. The opposing backronym is WET (Write Everything Twice), used humorously to describe code that violates DRY.
How are teams like yours balancing speed, quality, security, and AI in 2026? Download your copy and get real insights.
ACCELQ builds tests in plain English, no code, cuts maintenance 70%. Book a demo to see it across your entire stack!
BearQ continuously tests your app, reducing test maintenance and uncovering gaps scripted tests can miss.
Better than a generic video, see YOUR test, live, ready to show you what matters most: quality at scale.