Let me share with you something really controversial which came into my mind. Origins of the idea: • Code duplication is better then using the wrong abstraction • Every system evolves, its abstractions evolve, they come and go Also, I think it is not too bad to refer to abstractions as units (like in Unit tests). I also think about abstractions as an “extracted” “step in the process”, aka “new policy” in the system, which is “some kind of a restriction”. What I see in my codebase that introducing ANY abstraction has pros and cons. In terms of new (LAYERS!) abstractions (which hide the sides from each other) there are things which can be expressed EASIER/SHORTER/TERSER (these are the things the developer probably thinks and reasons about) BUT, there might be things in future which are not easier/shorter/terser, on the contrary HARDER/LONGER/MORE VERBOSE. One of my points is that the business logic kind of things (which would be nice to abstract away) are going to change in softwares evolution, it is just a matter of time. That means, there will be things which were just impossible to see are coming and now we have extra (layers of) abstractions in our way. Sure, we have to refactor! We have to 1. reuse the “corrupted” / “wrongly evolved” abstractions for creating new ones [OR] 2. (a.) dump the old (b.) just find something completely new which respects both the old and new requirements

I'm not sure why this is controversial outside of a lot (maybe most) programmers wanting universal low risk solutions and "best practices" to dominate coding. Complex abstractions can also help people appear more senior in some cases to justify higher salaries 🙂. That kind of thinking can help in CS programs and bigger corporate software companies, but if you read things from truly skilled programmers they usually have these more "controversial" opinions. One of my favorite examples of this is John Carmack on Inlined code (http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html) It is relatively simple advice but might run counter to someone who follows the dogma of always having small functions. Some anti-OOP, or pro functional rhetoric fits into this, so does "YAGNI" (which is generally anti-abstraction) although it runs counter to another coding acronym which is "DRY".

John Ousterhout argues in A Philosophy of Software Design that abstractions should be "deep" - simple interface, complex implementation. Such abstraction adds value. Small methods are often "shallow" (method declaration is about as complex as its implementation) so they don't add much value.