I've seen excessive abstraction kill projects time and time again. The crime scene is similar in every case:<p>- What if we ever need to change database server or driver? Proceeds to write a layer to abstract data access<p>- We might have different login forms one day? LoginFormFactory it is<p>- This code hits our KV Redis/memcache/NoSQL by calling the driver lib directly? Can't have that, I'll write a CacheStorage or DocumentStorage layer.<p>Over time, this defensive mentality produces codebases that are so bloated that no one in the team can confortably grasp all the moving parts despite the project not being rocket science.<p>At that point, devs rather quit or get a substantial raise in order to continue working and ultimately endup leaving to start a new project. But this time, they'll be sure to not make the same mistakes. This time, they'll abstract even more so "when one part of the project becomes bloated, it can be easily rewritten thanks to the abstractions". And the cycle continues.
I find that there's two core points that help me figure out where I'm missing some form of abstraction: the body of a function should only operate on a single level of abstraction, and it should only know technical details about one thing.<p>If you're writing some database code, having high-level fetchMyEntity() calls mixed with connection/resultset/cursor logic is bad news.<p>If you're writing something that reads from a message queue and stores the message in a database, the place where the two meet shouldn't know much of anything about either the message queue or the database.<p>Obviously, exceptions exist where these rules need to be broken, but I find they're fairly few and far between.
Lately I've been thinking about the similarities between the abstraction that results from post-hoc software refactoring and post-hoc mathematical proof "refactoring". In both cases the refactoring is an attempt towards a more ideal form, but that form is almost always more impenetrable to newcomers.<p>E.g., a quote about the mathematician Carl Gauss:<p>> Gauss' writing style was terse, polished, and devoid of motivation. Abel said, `He is like the fox, who effaces his tracks in the sand with his tail'. Gauss, in defense of his style, said, `no self-respecting architect leaves the scaffolding in place after completing the building'.
There's a difference between deduplication/extraction and abstraction which often seems to get lost. Abstraction is not about the mechanical reorganization of code. It is the structuring the code to follow a natural/logical abstraction that exists outside of the code. The first clue is the name of the abstraction. If it describes how the 'abstraction' works or what is going on inside it, then it's best to leave it. An abstraction should be able to opaquely represent what it is. This is the <i>value</i> of abstractions, it let's you not think about what's inside while working at a higher level.<p>A similar issue I have is with people constantly 'refactoring'. I choose to say I'm 'factoring' code instead. If you can't name the factors that you're separating then it's likely you'll change your mind an end up 'refactoring' it. Sometimes you take factored code and factor it further, which I don't have a different name for, just more factoring.
Introducing an abstraction is a way of extending the "base" language into the domain of the problem being solved. Viewed in this way, creating an inc_pair() function does not
make sense beyond applications that deal with incrementing stuff. On the other hand, if we are moving a player on a grid, move_diagonaly_up() makes sense and is worth introducing into the extended language vocabulary.
Rule of Three<p><a href="https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)" rel="nofollow">https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...</a>
Abstractions are of course due when time is right.<p>It's difficult to address but imo not be the goal from the get go, to introduce abstractions to a codebase.<p>There is also a cultural thing around abstractions where inexperienced developers look up to or are fascinated with the complexity of something or someone that brings that to the table.<p>It's also a common feature of certain so called architects, because they probably feel they need to some advanced techniques.<p>The thing is though, that when you have worked with developers or architects that advocates for simple abstractions, and it over time proves that is both efficient and cheap, then you start to doubt complexity in total.<p>Also remember that complexity is often not complex per se, as long as you spend time on breaking that complexity down.<p>And then you have a better fundamental platform for solving what you need to.<p>Simple code is fast code. And also easier to change.
Very insightful. I like thinking about software complexity and one of the concerns there to deal with complex software is that the design and intentions should be communicated (which means either documentation or exist as a common understanding of purpose and function).<p>From your perspective, it means that there is also a need to establish agreements on the levels, depth and ways abstractions in the code are formed. Indeed, I worked with software where the functions and operations weren't implemented in a messy way per sé, but the many levels of indirection, abstraction (and obscurement) made things just really difficult to read and a real tail-chaser when it came to maintenance.<p>Those levels can also make it much more difficult to understand the flow and the operations that are happening, because in many languages you pass references to data objects, so data gets changed in many ways.<p>Nice article, puts me into thinking mode again! :)
I totally agree that the cost of abstraction should become more important. It is often the number one cause of frustration when trying to add a new feature to an existing code base.
Building a mental model of any code base takes time. Abstractions for the sake of abstraction makes it harder to grasp.
Abstraction should be based on whether the abstraction makes it easier or harder to reason about: to see, to predict consequences of decisions, to diagnose causes of behaviour.<p>Usually, the established abstractions of the domain are an excellent guide. Even if you think they are sub-optimal objectively, they are easier to reason about for experts in that field.<p>I like the article's language of comtaining the "damage" code can do.
A C-style modularizarion technique I haven't seen used is long functions, with sections' variables' visibility limited by braces.
That's a really simply abstraction there, and I bet most people won't even call that an abstraction.<p>It's a bit like saying bricks are useless, by limiting the entire argument to a single brick.
These abstraction discussions seem to always result in commenters talking over each other. I would love to have these conversations rooted in a code sample. Otherwise no one is talking about the same thing.<p>If someone writes a blog series called “should this be abstracted, what’s the abstraction?” I think we would see some great discussion.
Structuring 1M line of code as one function or 1M functions is clearly equally absurd. What is the sweet spot? There must be an answer from psychology and/or information theory.