Hey Pete :) Really nice piece of reading! I will just add my two cents ;) I come from RoR ecosystem, so it might work a bit different here, but still I feel we should not fear “abstraction”— or maybe rather “decomposition”. Decomposing concepts into smaller chunks is a powerful way to improve code readability and make it easier to comprehend. But, I have to agree, that it is easy to take it too far and either overuse it (decompose more than needed) or just not use it right (use some pattern where it just does not fit). We usually proceed with development using TDD Outside-In approach — starting with high level specs and going into details later — this way we usually end up with what you refer to as “easy solution” first, and then just fine-tune it during refactoring phase — and this is when we need to be extra cautious not to overdo things ;) Also I cannot agree more about “interfaces” — if narrow and well defined, those might be useful here and there (especially if we use them for Wrapper/Facade), but many times interfaces (or additional layers) are introduced where likelihood of changing any library or solution is close to none. The bottom line is — abstraction is not inherently “dirty”, but we need to be very cautious not to make it so.