11 ms·

Premature Abstraction

182 points by arendjr 2y ago

Zambyte 2y ago
Anyone who wants to do a deep dive into understanding effective abstractions, I highly recommend SICP. The full book[0] and lectures[1] are available online for free. You don't have to know Scheme to follow along. [0] https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html https://mitp-content-server.mit.edu/books/content/sectbyfn/b... [1] https://ocw.mit.edu/courses/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video_galleries/video-lectures/ https://ocw.mit.edu/courses/6-001-structure-and-interpretati...
- morkalork 2y ago
  >You don't have to know Scheme to follow along. Is a hilarious understatement. No, you don't need to know it when you start the book but when you finish, you certainly will.
sevensor 2y ago
Although I agree with the recommendations, I cringe at the definition of abstraction. In a sane world, abstraction doesn't mean defining classes so much as it means identifying important unifying concepts. DRYing your code by moving a method to a common base class isn't abstraction in any important way, it's just adding a level of indirection. In fact, I'd argue that this example is the opposite of abstraction: it's concretion. Now every subclass relies implicitly on a particular implementation of that shared method. Not that doing this is never useful, but it's a mistake to call it abstraction when it's nothing of the sort. No wonder people complain that their abstractions leak.
- withinboredom 2y ago
  I'm currently dealing with a codebase that does this to a ridiculous extent. Like, literally, every change affects the entire project because everything is made of base-classes mixed in weird ways. Every concrete object inherits multiple base classes and no individual behavior. Imagine something like this: class Book extends ShelfableItem, Pagable, Authored, Readable, BaseBook {} It's absolutely insane.
  - patmorgan23 2y ago
    Oof. I know this is an example but all of those look like they would be better served as interfaces.
    - withinboredom 2y ago
      Yes. Did I mention there are interfaces too, with almost the same name, but it’s only used for the base classes. (Yes, there is only one implementation of all interfaces).
      - brabel 2y ago
        Having lots of interfaces for common things is not a bad thing. See how Rust traits work... even basic structs you create will probably implement lots of basic traits (some of which can be done automatically, thankfully) like `Display`, `Default`, several `From` or `Into` impls, `Clone`, `Copy` if your type is "light", `AsRef`, `Send` and many more! This makes code much more reusable as so many functions are written based on those basic traits alone. Of course, finding the right basic types is really hard and your company seems to have done that badly, but in principle, having some basic types to model very common "things" is a necessary thing.
        withinboredom 2y ago
        The issue isn't the interfaces; it's that there is only one implementation (the base classes) per interface—so why even bother having an interface? Otherwise, I agree with you to a degree. The main issue with the codebase is that if you want to, say, change the behavior of a Book, you have to go change the behavior of some base class (after working out which one is actually being called). This base class might be used in a Clock, Field, or Filesystem as well—something so conceivably far away that their similar behavior is a coincidence and not really related at all. Then you get to argue with the architect about whether "reading a book" is different than "reading a clock."
    - dakiol 2y ago
      It depends. Of course we don’t see the whole picture because it’s just an example by OP, but I also find weird that the de facto solution to abstract classes is: interfaces. Sometimes, duplication is better than interfaces.
- sevnin 2y ago
  If by abstraction you mean identifying unifying concepts then I cant understand how you reasoned yourself into thinking that identifying a common method and sharing it between multiple classes by the means of the super class is not abstraction. You have identified a commonality - the common code, common method. By your definition it's abstraction.
  - chowells 2y ago
    It's not abstraction because it's not presenting a simpler mental model. It's just shoving some code located somewhere else into scope. It's mere indirection.
  - mrkeen 2y ago
    Example of abstraction vs indirection: If I said 'User', we both know exactly what that means. It's so semantically simple that laypeople know what it means. But our implementations could vary wildly. Someone who's just taken Java 101 will be thinking of a class with getName() and setName(). But someone who's just taken SQL 101 will think of a User as an INT or UUID, where features are added by referencing that user's id from different tables. User is abstract because it's understandable and not locked into any particular implementation. I love Kafka. But it's a PITA to program against, at least in Java. I cannot code directly against it and always need to make my own wrapper classes to construct and poll it. I'll make ResumingKafkaReader and RewindingKafkaConsumerFactory, etc. These are not abstract, because they are very specific about what and how they do things. They are concrete behaviours wrapped with 1-2 levels of concrete indirection. However, I might inject one of my Kafka indirections into a business logic class, interfaced as a Supplier<User>, which makes it abstract. I can then unit test my class, safe in the knowledge that my class cannot know if a User came from Kafka or just a test stub. So I push back on the thesis of the article, and double-down on doing things abstractly first and foremost. This is closely related to the dependency inversion principle. Write (and test) your business classes around Users and other abstract things. Once you've done it wrong a few times and eventually gotten it right, then you can start writing the indirections (e.g. AbstractKafkaFactory) which the article rightly claims slow you down in the beginning.
- mannykannot 2y ago
  I came to say more-or-less the same thing. The author is making some valid points, but the moral is that premature reification of abstract concepts may be harmful, especially if there is something vague about them.
- bubblyworld 2y ago
  I had to mull over this for a while, but I think I agree - abstractions at a conceptual level are much more powerful than object-level "compression". Concepts/domain model/whatever tend to change over time though (at least in the business world, maybe not so much tooling etc). I think that's another source of leaky abstractions - things that conceptually made sense together at one point grow apart, and now you're left with common code that is deeply integrated but doesn't quite fit any more.
aswerty 2y ago
> Post-Architecture is a method of defining architecture incrementally, rather than designing it upfront For anyone else wondering what it means. I'm going to be honest, almost all architecture I've seen out in the wild has followed a more incremental approach. But then again everywhere I've worked hasn't separated the architecture/coding roles.
- tracker1 2y ago
  If you work with C# or Java in a lot of places, such as Banking in particular, you'll definitely see a lot of up-front architecture and excess abstractions early on.
recursivedoubts 2y ago
My general take (and w/ the caveat that every system is different) is as follows: - procedural code to enter into the system (and perhaps that's all you need) - object oriented code for domain modeling - functional code for data structure transformations & some light custom control flow implementation (but not too much) I like the imperative shell, functional core pattern quite a bit, and focusing on data structures is great advice as well. The anti-OO trend in the industry has been richly earned by the OO architecture astronauts[1], but the idea of gathering a data structure and the operations on that data structure in a single place, with data hiding, is a good one, particularly for domain modeling. In general I think we are maturing as an industry, recognizing that various approaches have their strengths and weaknesses and a good software engineer can mix and match them when building a successful software project. There is no silver bullet. If only someone had told us that years ago! [1] - https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
- kingofthehill98 2y ago
  That's the strategy I always take when designing a system. Funny that I never thought about it before, I think most PHP developers will relate to that aswell. - Procedural single point entrance into the system (network -> public/index.php, cli -> bin/console) - OOP core for business logic, heavily borrowed (copied) from Java OOP model - Functional code inside classes/methods whenever possible (callables/closures, array_map/filter/reduce/walk, illuminate/collections, etc.)
- bunderbunder 2y ago
  OO code for domain modeling might be, to date, the single greatest source of disillusionment in my career. There are absolutely use cases where it works very well. GUI toolkits come to mind. But for general line-of-business domain modeling, I keep noticing two big mismatches between the OO paradigm and the problem at hand. First and foremost, allowing subtyping into your business domain model is a trap. The problem is that your business rules are subject to change, you likely have limited or even no control over how they change, and the people who do get to make those decisions don't know and don't care about the Liskov Substitution Principle. In short, using one of the headline features of OOP for business domain modeling exposes you to outsize risk of being forced to start doing it wrong, regardless of your intentions or skill level. (Incidentally, this phenomenon is just a specific example of premature abstraction being the root of all evil.) And then, second, dynamic dispatch makes it harder for newcomers to figure out the business logic by reading the code. It creates a bit of a catch-22 situation where figuring out which methods will run when - an essential part of understanding how the code behaves - almost requires already knowing how the code works. Not actually, of course, but reading unfamiliar code that uses dynamic dispatch is and advanced skill, and nobody enjoys it. Also, this problem can easily be mitigated with documentation. But that solution is unsatisfying. Just using procedural code and banging out whatever boilerplate you need to get things working using static dispatch creates less additional work than what it takes to write and maintain satisfying documentation for an object-oriented codebase, and comes with the added advantage that it cannot fall out of sync with what the code actually does. Incidentally, Donald Knuth made a similar observation in his interview in the book Coders at Work. He expressed dissatisfaction with OOP on the grounds that, for the purposes of maintainability, he found code reuse to be less valuable than modifiability and readability.
t43562 2y ago
I like to start with a fairly unambitious bit of procedural code and gradually introduce abstractions when it starts to get complicated or repetitious. Straight code becomes functions, occasionally a group of functions cry out to become a class. In C++ this is a huge effort to do - change hurts more there. In python it's much less painful and I end up with a program that is some imperfect composite of object oriented with functions. Next week when I want it to do more I move it further down the road to structure. I also like keeping side effects in their own ghettos and extracting everything else out of those if possible but I'm not a big functional programming person - it's just about testing. Testing things with side effects is a pain.
- tracker1 2y ago
  I find that JS/TS also lends itself towards this in terms of Node/Deno/Bun usage for apps. You can have a file/module that simply exports a function, a collection of functions, a class, etc. It's easy to keep it simple and then combine with a mix of procedural, functional and oo concepts as best fits the use case.
- HdS84 2y ago
  Yes, I'm doing that a lot, too. I'm often astounded how hostile some languages are to later changes - e.g. java always feels resistant to change, while dotnet and especially python are more amenable. I.e. I totally transformed a program from function to oo in python without much sweat - would have been a total pain in dotnet or java
  - DarkNova6 2y ago
    Can you give examples for what you changed?
    - HdS84 2y ago
      Difficult on mobile and I'm without access to k PC ATM. Basically, my predecessor hat build a python program which had N modules which where applied to a data structure - maybe think of correction steps. First spell checking, than turn manual headlines into actual headlines etc. Originally, they operated on a global data structure, and every new module required calling it on the global structure, so extension was difficult. Worse, every module hat internal state, e.g. the number of spelling mistakes. Reporting these things at the end was cumbersome. There where "required" functions in each module, but it was difficult to newcomers to discover who they where. We changed it so that every step was a class which inherited from a base class, so adding a new step was as easy as inheriting from the base class. Furthermore, we added Auto discovery, so just adding the class in a module was sufficient to get it executed.
k__ 2y ago
Isn't that mostly a question of composability?
jimmaswell 2y ago
Fine blog post overall, but the author fell to premature abstraction themselves in declaring that little Foo class bad. It's entirely too generalized for me to say anything negative about at all. Depending on the context, a tiny class like that could be completely sensible or utterly unnecessary.
epgui 2y ago
The discussion of procedural code doesn't make sense to me, because it seems to mix together some orthogonal concepts. Procedural is not the opposite of object-oriented (nor is it particularly contrasting); idiomatic OOP is procedural to a large degree. Effective functional programming happens when you ditch the procedural approach in favour of a more declarative approach.
commandlinefan 2y ago
> The real problem with the class Foo above is that it is utterly and entirely unnecessary I see this sentiment a _lot_ in anti-OO rants, and the problem is that the ranter is missing the point of OO _entirely_. Hard to fault them, since missing the point of OO entirely is pretty common but... if you're creating classes as dumb-data wrappers and reflexively creating getters and setters for all of your private variables then yes what you're doing _is_ utterly and entirely unnecessary, but you're not doing object-oriented design at all. The idea, all the way back to the creation of OO, was to expose actions and hide data. If you're adding a lot of syntax just to turn around and expose your data, you're just doing procedural programming with a redundant syntax.
- HdS84 2y ago
  As someone who dies a lot of python, TS, dotnet and java - I disagree. The problem of dotnet and java is that everything is a object. And for many cases, I don't need that object at all, it can be a static class - but honestly, the python concept of a module fits a lot better. It's a grouping of functions in a module, not a class holding functions.
resters 2y ago
A well chosen abstraction dramatically simplifies code and understanding, and a poorly chosen abstraction has the opposite effect. When building a system some choices about abstractions can be made early, before the problem domain is fully understood. Sometimes they stand the test of time, other times they need to be reworked. Being aware of this and mindful of the importance of good abstractions is key to good system design.
feoren 2y ago
I know HN doesn't like quibbles about site design, but I'm literally having difficulty reading the article due to the font size being forced to be at least 1.3vw. Zooming out doesn't decrease the font size! Downvote if this is boring, but (a) I've never seen a site that did that before, so it's just notable from a "Daily WTF" kind of perspective, and (b) just in case the submitter is on HN: it's actually preventing me from reading the content (without changing it in DevTools anyway).
- arendjr 2y ago
  That’s useful feedback, thanks!
m3kw9 2y ago
Here’s the scenario, hot shot intern comes in, calls a meeting to use generics so things can be done “easier”. He does a good job at presenting it and its value, the dumbass team lead oks it. Fast forward 1 week everyone complains behind on how much pain it is to use
MisterBastahrd 2y ago
There's no greater joy in life than jumping through an abstract object, an object interface, and a factory method only to find out that the factory only services one object.
phkahler 2y ago
>> Often, an abstraction doesn’t truly hide the data structures underneath, but it is bound by the limitations of the initial data structure(s) used to implement it. You want to refactor and use a new data structure? Chances are you need a new abstraction. Data structures are abstractions :-)
scotty79 2y ago
I would love a language that has this gradual evolutional abstracting as a core concern. That makes it easy. Where you can start from simplest imperative code and easily abstract it as the need for this arises. For example a language that requires "this." or "self." prefix is not such language because you can't easily turn a script or a function into a method of some object.
- teodorlu 2y ago
  > I would love a language that has this gradual evolutional abstracting as a core concern. That makes it easy. Where you can start from simplest imperative code and easily abstract it as the need for this arises. This is about how I write Clojure. I start out with some code that does the thing I want. Either effectfull code that "does the thing" or functions from data to data. After a while, I feel like I'm missing a domain operation or two. At that point I've got an idea about what kind of abstraction I'm missing. Rafael Dittwald describes the process of looking for domain operations and domain entities nicely here: https://youtu.be/vK1DazRK_a0 https://youtu.be/vK1DazRK_a0
aliasxneo 2y ago
I'm not "formally" trained in software engineering and am primarily self-taught. This area, in particular, has been confusing to me over the years, especially after consuming so many contradictory blog posts. I tried to model DDD in a recent Golang project and am mostly unhappy with the result. Perhaps in my eagerness, I fell into the trap of premature abstraction, but there's not anything in particular that I can point to that might lead to that conclusion. It just feels like the overall code base is more challenging to read and has a ton of indirection. The feeling is made worse when I consider how much extra time I spent trying to be authentic in implementing it. Now, I'm starting a new project, and I'm left in this uncertain state, not knowing what to do. Is there a fine balance? How is it achieved? I appreciate the author's attempt at bringing clarity, but I honestly walked away feeling even more confident that I don't understand how this all works out.
- RaftPeople 2y ago
  > I'm not "formally" trained in software engineering and am primarily self-taught Welcome to the club and I wouldn't be too worried about it (but definitely read and learn what others have figured out). Software design and development is still an unsolved problem. The industry has not collectively found a foundational set of standard practices that apply across the board other than some of the most basic (e.g. organization is good). You can tell that it's not solved by the relentless flow of industry trends that become the new "best practice" until some years later when we figure out "well, that approach has these pros and these cons and tends to fit with these types of problems, but definitely not a silver bullet, let's try the next thing" Regarding your specific issue on your new project: just be pragmatic, get it working and learn from your decisions, it's all just a collection of pros and cons and the analysis of pro vs con changes depending on the angle you look at it (e.g. short term vs long term, slow changing environment vs fast changing environment, cost to value ratio, etc., etc., etc.)
- marcosdumay 2y ago
  The one point of DDD is that you make a dictionary of all of the domain terms and get everybody to accept them. You can cut those 4 pages and throw the rest of the book away. But it is one of the best books on software engineering, and only gets better once you do that.
cryptica 2y ago
Though I agree about the point about not creating objects/instances where a pure function will get the job done, I disagree with the general stance against OOP. I think OOP is absolutely essential to simplicity. FP tends to lead to too many indirections with data traversing too many conceptual boundaries. FP (if used dogmatically) tends to encourage low cohesion. I want high cohesion and loose coupling. Some degree of co-location of state and logic is important since that affects cohesion and coupling of my modules. The key to good OOP is to aim to only pass simple primitives or simple cloned objects as arguments to methods/functions. 'Spooky action at a distance' is really the only major issue with 'OOP' and it can be easily solved by simple pass-by-value function signatures. So really, it's not a fundamental issue with OOP itself. OOP doesn't demand pass by reference. Alan Kay emphasized messaging; which is more leaning on 'pass by value'; a message is information, not an object. We shouldn't throw out the baby with the bathwater. When I catch a taxi, do I have to provide the taxi driver with a jerrycan full of petrol and a steering wheel? No. I just give the taxi driver the message of where I want to go. The taxi driver is responsible for the state of his car. I give him a message, not objects. If I have to give a taxi driver a jerrycan full of petrol, that's the definition of a leaky abstraction... Possibly literally in this case. That said, I generally agree with this article. That's why I tend to write everything in 1 file at the beginning and wait for the file size to become a problem before breaking things up. There are many different ways to slice things up and if you don't have a complete understanding of your business domain and possible future requirement changes, there is no way you will come up with the best abstractions and it's going to cost you dearly in the medium and long term. A lot of developers throw their arms up and say stuff like "We cannot anticipate future requirement changes"... Well of course, not on day 1 of your new system!!! You shouldn't be creating complex abstractions from the beginning when you haven't fully absorbed the problem domain. You're locking yourself into anti-patterns and lots of busy-work by forcing yourself to constantly re-imagine your flawed original vision. It's easier to come up with a good vision for the future if you do it from scratch without conceptual baggage. Otherwise, you're just seeding bias into the project. Once you have absorbed it, you will see, you CAN predict many possible requirement changes. It will impact your architecture positively. Coming up with good abstractions is really difficult. It's not about intelligence because even top engineers working in big tech struggle with it. Most of the working code we see is spaghetti.
jaynate 2y ago
Gall’s law: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” Your theory of premature architecture reinforces Gall’s law. This is from the book Systemantics: How systems work and especially how they fail (1977). https://en.wikipedia.org/wiki/Systemantics https://en.wikipedia.org/wiki/Systemantics
- arendjr 2y ago
  I like this one, thanks!
TurboHaskal 2y ago
It seems to me the author just wants multiple dispatch.
OhMeadhbh 2y ago
I think there's plenty of good advice in this post, though the OP doesn't talk as much about the evils of premature abstraction as one might like. Still, they do talk about how to avoid it using reasonable programming guidelines. In the talk about data structures, I was reminded of Fred Brooks quote from MMM: "Show me your flowcharts, and conceal your table, and I shall continue to be mystified; show me your tables and and I won't usually need your flowchart; it'll be obvious." Several people have translated it to something like "Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious," for a modern audience. Several years ago I was happy to work with several people with an interest in philosophical history. We whiled away the hours thinking about whether these quotes represented something of the tension between Hericlitus (You cannot step into the same river twice) and Plato (everything is form and substance.) So... I think the observation about the alternating utility of form and function is an old one.
- arendjr 2y ago
  Love it! Great quote and very on point. As for Heraclitus vs. Plato, I think the lesson I’m trying to teach is to not pick a side until you understand each position’s implications and which of those might be more beneficial to the problem at hand ;)
ImHereToVote 2y ago
This is nothing to be ashamed of. We have all been there. I mean, I haven't.
agentultra 2y ago
This seems more like premature indirection than abstraction. There are other design “paradigms,” such as denotational design. You start with and build from abstractions.
- vilunov 2y ago
  I used to read and write a lot of Scala and a bit of Haskell code which claims to be very similar to what I think you're mentioning here. There people also start with defining the domain in interfaces (algebras, eDSLs) and data types. In the end it's still the same indirection and abstraction as in any other Java or Go codebase, and it prevents the developer from easily accessing the actual logic of the program.
  - agentultra 2y ago
    What I find difficult to understand here is that the logic of the program, in the case of a Haskell-like language, is encoded in the types. I don’t need to look at the definition of a Monoid instance for a type (unless in rare cases it matter for some reason). I know there’s an identity element of the type and there’s a binary relation that combines elements of the type. Any type that’s a lawful Monoid works the same way. And it goes up from there. Denotational design is significantly different from an operational design. It’s not surprising that most programmers are taught and tend to think in terms of how computations are carried out instead of what computations are needed and the ways we can compose them. I still struggle with it at times. I classify it separately from “indirection,” because of the laws that govern a design process like that. The same rules used in algebra work in programs where you can rely on being able to substitute terms for symbols representing those terms. And algebra seems to have been a rather successful language for manipulating expressions. Where it does break down though is at the edges where we need to interact with run time exceptions, the state of resources external to the process, etc. Even in Haskell you can write your code procedurally if you want. You won’t get the benefits of denotational design but at least you’ll still have a pretty decent type system that helps you with refactoring and extracting “logic” later on into something more understandable and easier to work with.
BobbyTables2 2y ago
Premature Abstraction is a common problem, affecting developers of all ages. Most are too embarrassed to talk about it. Fortunately, there are non-invasive therapies that can reduce the frequency of occurrence.
- arendjr 2y ago
  xD In all seriousness though, you do hit a great point. The moment you stop being embarrassed about your mistakes and set your ego aside, is the moment that you can truly start learning from those same mistakes. At some point it even becomes the only way you can move forward, unless you want to stay boxed inside a niche of expertise defined by your own self-set boundaries.
gspencley 2y ago
I've been a software eng professionally for 25 years. Have been coding more like 30 - 35. There is a fundamental principal here that I agree with and it surrounds a code smell that Martin Fowler termed "Speculative Generality" in his book "Refactoring." Speculative Generality is when you don't know what will have to change in the future and so you abstract literally everything and make as many things "generic" as you possibly can in the chance that one of those generic abstractions may prove useful. The result is a confusing mess of unnecessary abstractions that adds complexity. However, yet again I find myself staring at a reactionary post. If developers get themselves into trouble through speculative generality, then the answer is clearly "Primitive Obsession" (another code smell identified in "Refactoring") right? Primitive Obsession is the polar opposite of abstraction. It dispenses with the introduction of high-level APIs that make working with code intuitive, and instead insists on working with native primitive types directly. Primitive Obsession often comes from a well meaning initiative to not "abstract prematurely." Why create a "Money" class when you can just store your currency figure in an integer? Why create a "PersonName" class when you can just pass strings around? If you're working in a language that supports classes and functions, why create a class to group common logical operations around a single data structure when you can instead introduce functions even if they take more parameters and could potentially lead to other problems such as "Shotgun Surgery." This is not to say that the author is wrong or that one should embrace "premature abstraction." Only that I see a lot of reactionary thinking in software engineering. Most paradigms that we have today were developed in order to solve a very real problem around complexity at the time. Without understanding what that complexity was, historically, you are doomed to repeat the mistakes that the thinkers at the time were trying to address. And of course, those iterations introduced new problems. Premature Abstraction IS a "foot gun." What software engineers need to remember is that the point of Design Patterns, the point of Abstractions, the point of High-Level languages and API design is to SIMPLIFY. One term we hear a lot, that I have been on the war path against for the past decade or two is "over engineering." As engineers, part of our jobs is to find the simplest solution to a given problem. If, in your inappropriate use of a given design pattern or abstraction, you end up making something unnecessarily complicated, you did not "over engineer" it. You engaged in BAD engineering. When it comes to abstractions, like anything else, the key to gain the experience needed to understand a) why abstractions are useful b) when abstractions can introduce complexity and then apply that to a prediction of what will likely benefit from abstraction because it is something that will be very difficult to change later. All software changes. That's the nature of software and why software exists in the first place. Change is the strength of software but also a source of complexity. The challenge of writing code comes from change management. Being able to identify which areas of your code are going to be very difficult to change later, and to find strategies for facilitating that change. Premature Abstraction throws abstractions at everything, even things that are unlikely to change, without the recognition that doing so makes the code more complex not less. Primitive Obsession says "we can always abstract this later if we need to" when in some situations, that will prove impossible(ex: integrating with and coupling to a 3rd party vendor; a form of "vendor lock-in" through code that is often seen). /stream-of-consciousness-thoughts-on-article
sesm 2y ago
Premature abstraction and premature optimization are just instances of Heffalump Trap pattern.
stretch1414 2y ago
Wonderful write-up. One way I really try to avoid premature abstractions is co-locating code wherever it is used. If you don't try to put everything in a shared lib or utils, you keep the surface area small. Putting a function in the same file (or same folder) makes it clear that it is meant to be used in that folder only. You have to be diligent about your imports though and be sure you don't have some crazy relative paths. Then, if you find yourself with that same function in lots of places in your code, you might have an stumbled upon an abstraction. That's when you put it in the shared lib or utils folder. But maybe not, maybe that abstraction should stay in a nested folder because it is specifically used for a subset of problems. Again, that's to avoid over-abstracting. If you are only using it for 3 use cases that are all within the same parent folder path (just different sub-folders), then only co-locate it as far up in the file tree as is absolutely necessary for keeping the import simple. Again, it requires due diligence, but the compartmentalization of the folder structure feels elegant in its simplicity.
ChrisMarshallNY 2y ago
In my experience, I've always found the devil to be in the [late] details. I have learned (the hard way), that, no matter how far I go down the rabbithole, in architecture, I am never a match for Reality. I. Just. Can't. Plan. For. Everything. I've learned to embrace the suck, so to speak. I admit that I don't know how things will turn out, once I get into the bush, so I try to design flexible architectures. Flexibility sometimes comes as abstractions; forming natural "pivot points," but it can also come from leaving some stuff to be "dealt with later," and segmenting the architecture well enough to allow these to be truly autonomous. That can mean a modular architecture, with whitebox "APIs," between components. People are correct in saying that OO can lead to insane codeballs, but I find that this is usually because someone thought they had something that would work for everything, and slammed into some devilish details, down the road, and didn't want to undo the work they already did. I have learned to be willing to throw out weeks worth of work, if I determine the architecture was a bad bet. It happens a lot less, these days, than it used to. Hurts like hell, but I've found that it is often beneficial to do stuff I don't want to do. A couple of years ago, I threw out an almost-complete app, because it was too far off the beam. The rewrite works great, and has been shipping since January. Anyway, I have my experience, and it often seems to be very different from that of others. I tend to be the one going back into my code, months, or years, after I wrote it, so I've learned to leave stuff that I like; not what someone else says it should be like, or that lets me tick off a square in Buzzword Bingo. My stuff works, ships, and lasts (sometimes, for decades).
yellowapple 2y ago
> /// BAD: This mutates `input`, which may be unexpected by the caller. > [...] > /// GOOD: `input` is preserved and a new object is created for the output. Neither of these are good or bad without knowing their context and understanding their tradeoffs. In particular, sometimes you want to mutate an existing object instead of duplicating it, especially if it's a big object that takes awhile to duplicate.
- mrkeen 2y ago
  If you don't mutate, you don't need to duplicate.

182 points by arendjr 2y ago

Anyone who wants to do a deep dive into understanding effective abstractions, I highly recommend SICP. The full book[0] and lectures[1] are available online for free. You don't have to know Scheme to follow along. [0] https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html https://mitp-content-server.mit.edu/books/content/sectbyfn/b... [1] https://ocw.mit.edu/courses/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video_galleries/video-lectures/ https://ocw.mit.edu/courses/6-001-structure-and-interpretati...

morkalork 2y ago
>You don't have to know Scheme to follow along. Is a hilarious understatement. No, you don't need to know it when you start the book but when you finish, you certainly will.

sevensor 2y ago

Although I agree with the recommendations, I cringe at the definition of abstraction. In a sane world, abstraction doesn't mean defining classes so much as it means identifying important unifying concepts. DRYing your code by moving a method to a common base class isn't abstraction in any important way, it's just adding a level of indirection. In fact, I'd argue that this example is the opposite of abstraction: it's concretion. Now every subclass relies implicitly on a particular implementation of that shared method. Not that doing this is never useful, but it's a mistake to call it abstraction when it's nothing of the sort. No wonder people complain that their abstractions leak.

withinboredom 2y ago
I'm currently dealing with a codebase that does this to a ridiculous extent. Like, literally, every change affects the entire project because everything is made of base-classes mixed in weird ways. Every concrete object inherits multiple base classes and no individual behavior. Imagine something like this: class Book extends ShelfableItem, Pagable, Authored, Readable, BaseBook {} It's absolutely insane.
- patmorgan23 2y ago
  Oof. I know this is an example but all of those look like they would be better served as interfaces.
  - withinboredom 2y ago
    Yes. Did I mention there are interfaces too, with almost the same name, but it’s only used for the base classes. (Yes, there is only one implementation of all interfaces).
    - brabel 2y ago
      Having lots of interfaces for common things is not a bad thing. See how Rust traits work... even basic structs you create will probably implement lots of basic traits (some of which can be done automatically, thankfully) like `Display`, `Default`, several `From` or `Into` impls, `Clone`, `Copy` if your type is "light", `AsRef`, `Send` and many more! This makes code much more reusable as so many functions are written based on those basic traits alone. Of course, finding the right basic types is really hard and your company seems to have done that badly, but in principle, having some basic types to model very common "things" is a necessary thing.
      - withinboredom 2y ago
        The issue isn't the interfaces; it's that there is only one implementation (the base classes) per interface—so why even bother having an interface? Otherwise, I agree with you to a degree. The main issue with the codebase is that if you want to, say, change the behavior of a Book, you have to go change the behavior of some base class (after working out which one is actually being called). This base class might be used in a Clock, Field, or Filesystem as well—something so conceivably far away that their similar behavior is a coincidence and not really related at all. Then you get to argue with the architect about whether "reading a book" is different than "reading a clock."
  - dakiol 2y ago
    It depends. Of course we don’t see the whole picture because it’s just an example by OP, but I also find weird that the de facto solution to abstract classes is: interfaces. Sometimes, duplication is better than interfaces.
sevnin 2y ago
If by abstraction you mean identifying unifying concepts then I cant understand how you reasoned yourself into thinking that identifying a common method and sharing it between multiple classes by the means of the super class is not abstraction. You have identified a commonality - the common code, common method. By your definition it's abstraction.
- chowells 2y ago
  It's not abstraction because it's not presenting a simpler mental model. It's just shoving some code located somewhere else into scope. It's mere indirection.
- mrkeen 2y ago
  Example of abstraction vs indirection: If I said 'User', we both know exactly what that means. It's so semantically simple that laypeople know what it means. But our implementations could vary wildly. Someone who's just taken Java 101 will be thinking of a class with getName() and setName(). But someone who's just taken SQL 101 will think of a User as an INT or UUID, where features are added by referencing that user's id from different tables. User is abstract because it's understandable and not locked into any particular implementation. I love Kafka. But it's a PITA to program against, at least in Java. I cannot code directly against it and always need to make my own wrapper classes to construct and poll it. I'll make ResumingKafkaReader and RewindingKafkaConsumerFactory, etc. These are not abstract, because they are very specific about what and how they do things. They are concrete behaviours wrapped with 1-2 levels of concrete indirection. However, I might inject one of my Kafka indirections into a business logic class, interfaced as a Supplier<User>, which makes it abstract. I can then unit test my class, safe in the knowledge that my class cannot know if a User came from Kafka or just a test stub. So I push back on the thesis of the article, and double-down on doing things abstractly first and foremost. This is closely related to the dependency inversion principle. Write (and test) your business classes around Users and other abstract things. Once you've done it wrong a few times and eventually gotten it right, then you can start writing the indirections (e.g. AbstractKafkaFactory) which the article rightly claims slow you down in the beginning.
mannykannot 2y ago
I came to say more-or-less the same thing. The author is making some valid points, but the moral is that premature reification of abstract concepts may be harmful, especially if there is something vague about them.
bubblyworld 2y ago
I had to mull over this for a while, but I think I agree - abstractions at a conceptual level are much more powerful than object-level "compression". Concepts/domain model/whatever tend to change over time though (at least in the business world, maybe not so much tooling etc). I think that's another source of leaky abstractions - things that conceptually made sense together at one point grow apart, and now you're left with common code that is deeply integrated but doesn't quite fit any more.

aswerty 2y ago

> Post-Architecture is a method of defining architecture incrementally, rather than designing it upfront For anyone else wondering what it means. I'm going to be honest, almost all architecture I've seen out in the wild has followed a more incremental approach. But then again everywhere I've worked hasn't separated the architecture/coding roles.

tracker1 2y ago
If you work with C# or Java in a lot of places, such as Banking in particular, you'll definitely see a lot of up-front architecture and excess abstractions early on.

recursivedoubts 2y ago

My general take (and w/ the caveat that every system is different) is as follows: - procedural code to enter into the system (and perhaps that's all you need) - object oriented code for domain modeling - functional code for data structure transformations & some light custom control flow implementation (but not too much) I like the imperative shell, functional core pattern quite a bit, and focusing on data structures is great advice as well. The anti-OO trend in the industry has been richly earned by the OO architecture astronauts[1], but the idea of gathering a data structure and the operations on that data structure in a single place, with data hiding, is a good one, particularly for domain modeling. In general I think we are maturing as an industry, recognizing that various approaches have their strengths and weaknesses and a good software engineer can mix and match them when building a successful software project. There is no silver bullet. If only someone had told us that years ago! [1] - https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

kingofthehill98 2y ago
That's the strategy I always take when designing a system. Funny that I never thought about it before, I think most PHP developers will relate to that aswell. - Procedural single point entrance into the system (network -> public/index.php, cli -> bin/console) - OOP core for business logic, heavily borrowed (copied) from Java OOP model - Functional code inside classes/methods whenever possible (callables/closures, array_map/filter/reduce/walk, illuminate/collections, etc.)
bunderbunder 2y ago
OO code for domain modeling might be, to date, the single greatest source of disillusionment in my career. There are absolutely use cases where it works very well. GUI toolkits come to mind. But for general line-of-business domain modeling, I keep noticing two big mismatches between the OO paradigm and the problem at hand. First and foremost, allowing subtyping into your business domain model is a trap. The problem is that your business rules are subject to change, you likely have limited or even no control over how they change, and the people who do get to make those decisions don't know and don't care about the Liskov Substitution Principle. In short, using one of the headline features of OOP for business domain modeling exposes you to outsize risk of being forced to start doing it wrong, regardless of your intentions or skill level. (Incidentally, this phenomenon is just a specific example of premature abstraction being the root of all evil.) And then, second, dynamic dispatch makes it harder for newcomers to figure out the business logic by reading the code. It creates a bit of a catch-22 situation where figuring out which methods will run when - an essential part of understanding how the code behaves - almost requires already knowing how the code works. Not actually, of course, but reading unfamiliar code that uses dynamic dispatch is and advanced skill, and nobody enjoys it. Also, this problem can easily be mitigated with documentation. But that solution is unsatisfying. Just using procedural code and banging out whatever boilerplate you need to get things working using static dispatch creates less additional work than what it takes to write and maintain satisfying documentation for an object-oriented codebase, and comes with the added advantage that it cannot fall out of sync with what the code actually does. Incidentally, Donald Knuth made a similar observation in his interview in the book Coders at Work. He expressed dissatisfaction with OOP on the grounds that, for the purposes of maintainability, he found code reuse to be less valuable than modifiability and readability.

t43562 2y ago

I like to start with a fairly unambitious bit of procedural code and gradually introduce abstractions when it starts to get complicated or repetitious. Straight code becomes functions, occasionally a group of functions cry out to become a class. In C++ this is a huge effort to do - change hurts more there. In python it's much less painful and I end up with a program that is some imperfect composite of object oriented with functions. Next week when I want it to do more I move it further down the road to structure. I also like keeping side effects in their own ghettos and extracting everything else out of those if possible but I'm not a big functional programming person - it's just about testing. Testing things with side effects is a pain.

tracker1 2y ago
I find that JS/TS also lends itself towards this in terms of Node/Deno/Bun usage for apps. You can have a file/module that simply exports a function, a collection of functions, a class, etc. It's easy to keep it simple and then combine with a mix of procedural, functional and oo concepts as best fits the use case.
HdS84 2y ago
Yes, I'm doing that a lot, too. I'm often astounded how hostile some languages are to later changes - e.g. java always feels resistant to change, while dotnet and especially python are more amenable. I.e. I totally transformed a program from function to oo in python without much sweat - would have been a total pain in dotnet or java
- DarkNova6 2y ago
  Can you give examples for what you changed?
  - HdS84 2y ago
    Difficult on mobile and I'm without access to k PC ATM. Basically, my predecessor hat build a python program which had N modules which where applied to a data structure - maybe think of correction steps. First spell checking, than turn manual headlines into actual headlines etc. Originally, they operated on a global data structure, and every new module required calling it on the global structure, so extension was difficult. Worse, every module hat internal state, e.g. the number of spelling mistakes. Reporting these things at the end was cumbersome. There where "required" functions in each module, but it was difficult to newcomers to discover who they where. We changed it so that every step was a class which inherited from a base class, so adding a new step was as easy as inheriting from the base class. Furthermore, we added Auto discovery, so just adding the class in a module was sufficient to get it executed.

k__ 2y ago

Isn't that mostly a question of composability?

jimmaswell 2y ago

Fine blog post overall, but the author fell to premature abstraction themselves in declaring that little Foo class bad. It's entirely too generalized for me to say anything negative about at all. Depending on the context, a tiny class like that could be completely sensible or utterly unnecessary.

epgui 2y ago

The discussion of procedural code doesn't make sense to me, because it seems to mix together some orthogonal concepts. Procedural is not the opposite of object-oriented (nor is it particularly contrasting); idiomatic OOP is procedural to a large degree. Effective functional programming happens when you ditch the procedural approach in favour of a more declarative approach.

commandlinefan 2y ago

> The real problem with the class Foo above is that it is utterly and entirely unnecessary I see this sentiment a _lot_ in anti-OO rants, and the problem is that the ranter is missing the point of OO _entirely_. Hard to fault them, since missing the point of OO entirely is pretty common but... if you're creating classes as dumb-data wrappers and reflexively creating getters and setters for all of your private variables then yes what you're doing _is_ utterly and entirely unnecessary, but you're not doing object-oriented design at all. The idea, all the way back to the creation of OO, was to expose actions and hide data. If you're adding a lot of syntax just to turn around and expose your data, you're just doing procedural programming with a redundant syntax.

HdS84 2y ago
As someone who dies a lot of python, TS, dotnet and java - I disagree. The problem of dotnet and java is that everything is a object. And for many cases, I don't need that object at all, it can be a static class - but honestly, the python concept of a module fits a lot better. It's a grouping of functions in a module, not a class holding functions.

resters 2y ago

A well chosen abstraction dramatically simplifies code and understanding, and a poorly chosen abstraction has the opposite effect. When building a system some choices about abstractions can be made early, before the problem domain is fully understood. Sometimes they stand the test of time, other times they need to be reworked. Being aware of this and mindful of the importance of good abstractions is key to good system design.

feoren 2y ago

I know HN doesn't like quibbles about site design, but I'm literally having difficulty reading the article due to the font size being forced to be at least 1.3vw. Zooming out doesn't decrease the font size! Downvote if this is boring, but (a) I've never seen a site that did that before, so it's just notable from a "Daily WTF" kind of perspective, and (b) just in case the submitter is on HN: it's actually preventing me from reading the content (without changing it in DevTools anyway).

arendjr 2y ago
That’s useful feedback, thanks!

m3kw9 2y ago

Here’s the scenario, hot shot intern comes in, calls a meeting to use generics so things can be done “easier”. He does a good job at presenting it and its value, the dumbass team lead oks it. Fast forward 1 week everyone complains behind on how much pain it is to use

MisterBastahrd 2y ago

There's no greater joy in life than jumping through an abstract object, an object interface, and a factory method only to find out that the factory only services one object.

phkahler 2y ago

>> Often, an abstraction doesn’t truly hide the data structures underneath, but it is bound by the limitations of the initial data structure(s) used to implement it. You want to refactor and use a new data structure? Chances are you need a new abstraction. Data structures are abstractions :-)

scotty79 2y ago

I would love a language that has this gradual evolutional abstracting as a core concern. That makes it easy. Where you can start from simplest imperative code and easily abstract it as the need for this arises. For example a language that requires "this." or "self." prefix is not such language because you can't easily turn a script or a function into a method of some object.

teodorlu 2y ago
> I would love a language that has this gradual evolutional abstracting as a core concern. That makes it easy. Where you can start from simplest imperative code and easily abstract it as the need for this arises. This is about how I write Clojure. I start out with some code that does the thing I want. Either effectfull code that "does the thing" or functions from data to data. After a while, I feel like I'm missing a domain operation or two. At that point I've got an idea about what kind of abstraction I'm missing. Rafael Dittwald describes the process of looking for domain operations and domain entities nicely here: https://youtu.be/vK1DazRK_a0 https://youtu.be/vK1DazRK_a0

aliasxneo 2y ago

I'm not "formally" trained in software engineering and am primarily self-taught. This area, in particular, has been confusing to me over the years, especially after consuming so many contradictory blog posts. I tried to model DDD in a recent Golang project and am mostly unhappy with the result. Perhaps in my eagerness, I fell into the trap of premature abstraction, but there's not anything in particular that I can point to that might lead to that conclusion. It just feels like the overall code base is more challenging to read and has a ton of indirection. The feeling is made worse when I consider how much extra time I spent trying to be authentic in implementing it. Now, I'm starting a new project, and I'm left in this uncertain state, not knowing what to do. Is there a fine balance? How is it achieved? I appreciate the author's attempt at bringing clarity, but I honestly walked away feeling even more confident that I don't understand how this all works out.

RaftPeople 2y ago
> I'm not "formally" trained in software engineering and am primarily self-taught Welcome to the club and I wouldn't be too worried about it (but definitely read and learn what others have figured out). Software design and development is still an unsolved problem. The industry has not collectively found a foundational set of standard practices that apply across the board other than some of the most basic (e.g. organization is good). You can tell that it's not solved by the relentless flow of industry trends that become the new "best practice" until some years later when we figure out "well, that approach has these pros and these cons and tends to fit with these types of problems, but definitely not a silver bullet, let's try the next thing" Regarding your specific issue on your new project: just be pragmatic, get it working and learn from your decisions, it's all just a collection of pros and cons and the analysis of pro vs con changes depending on the angle you look at it (e.g. short term vs long term, slow changing environment vs fast changing environment, cost to value ratio, etc., etc., etc.)
marcosdumay 2y ago
The one point of DDD is that you make a dictionary of all of the domain terms and get everybody to accept them. You can cut those 4 pages and throw the rest of the book away. But it is one of the best books on software engineering, and only gets better once you do that.

cryptica 2y ago

Though I agree about the point about not creating objects/instances where a pure function will get the job done, I disagree with the general stance against OOP. I think OOP is absolutely essential to simplicity. FP tends to lead to too many indirections with data traversing too many conceptual boundaries. FP (if used dogmatically) tends to encourage low cohesion. I want high cohesion and loose coupling. Some degree of co-location of state and logic is important since that affects cohesion and coupling of my modules. The key to good OOP is to aim to only pass simple primitives or simple cloned objects as arguments to methods/functions. 'Spooky action at a distance' is really the only major issue with 'OOP' and it can be easily solved by simple pass-by-value function signatures. So really, it's not a fundamental issue with OOP itself. OOP doesn't demand pass by reference. Alan Kay emphasized messaging; which is more leaning on 'pass by value'; a message is information, not an object. We shouldn't throw out the baby with the bathwater. When I catch a taxi, do I have to provide the taxi driver with a jerrycan full of petrol and a steering wheel? No. I just give the taxi driver the message of where I want to go. The taxi driver is responsible for the state of his car. I give him a message, not objects. If I have to give a taxi driver a jerrycan full of petrol, that's the definition of a leaky abstraction... Possibly literally in this case. That said, I generally agree with this article. That's why I tend to write everything in 1 file at the beginning and wait for the file size to become a problem before breaking things up. There are many different ways to slice things up and if you don't have a complete understanding of your business domain and possible future requirement changes, there is no way you will come up with the best abstractions and it's going to cost you dearly in the medium and long term. A lot of developers throw their arms up and say stuff like "We cannot anticipate future requirement changes"... Well of course, not on day 1 of your new system!!! You shouldn't be creating complex abstractions from the beginning when you haven't fully absorbed the problem domain. You're locking yourself into anti-patterns and lots of busy-work by forcing yourself to constantly re-imagine your flawed original vision. It's easier to come up with a good vision for the future if you do it from scratch without conceptual baggage. Otherwise, you're just seeding bias into the project. Once you have absorbed it, you will see, you CAN predict many possible requirement changes. It will impact your architecture positively. Coming up with good abstractions is really difficult. It's not about intelligence because even top engineers working in big tech struggle with it. Most of the working code we see is spaghetti.

jaynate 2y ago

Gall’s law: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” Your theory of premature architecture reinforces Gall’s law. This is from the book Systemantics: How systems work and especially how they fail (1977). https://en.wikipedia.org/wiki/Systemantics https://en.wikipedia.org/wiki/Systemantics

arendjr 2y ago
I like this one, thanks!

TurboHaskal 2y ago

It seems to me the author just wants multiple dispatch.

OhMeadhbh 2y ago

I think there's plenty of good advice in this post, though the OP doesn't talk as much about the evils of premature abstraction as one might like. Still, they do talk about how to avoid it using reasonable programming guidelines. In the talk about data structures, I was reminded of Fred Brooks quote from MMM: "Show me your flowcharts, and conceal your table, and I shall continue to be mystified; show me your tables and and I won't usually need your flowchart; it'll be obvious." Several people have translated it to something like "Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious," for a modern audience. Several years ago I was happy to work with several people with an interest in philosophical history. We whiled away the hours thinking about whether these quotes represented something of the tension between Hericlitus (You cannot step into the same river twice) and Plato (everything is form and substance.) So... I think the observation about the alternating utility of form and function is an old one.

arendjr 2y ago
Love it! Great quote and very on point. As for Heraclitus vs. Plato, I think the lesson I’m trying to teach is to not pick a side until you understand each position’s implications and which of those might be more beneficial to the problem at hand ;)

ImHereToVote 2y ago

This is nothing to be ashamed of. We have all been there. I mean, I haven't.

agentultra 2y ago

This seems more like premature indirection than abstraction. There are other design “paradigms,” such as denotational design. You start with and build from abstractions.

vilunov 2y ago
I used to read and write a lot of Scala and a bit of Haskell code which claims to be very similar to what I think you're mentioning here. There people also start with defining the domain in interfaces (algebras, eDSLs) and data types. In the end it's still the same indirection and abstraction as in any other Java or Go codebase, and it prevents the developer from easily accessing the actual logic of the program.
- agentultra 2y ago
  What I find difficult to understand here is that the logic of the program, in the case of a Haskell-like language, is encoded in the types. I don’t need to look at the definition of a Monoid instance for a type (unless in rare cases it matter for some reason). I know there’s an identity element of the type and there’s a binary relation that combines elements of the type. Any type that’s a lawful Monoid works the same way. And it goes up from there. Denotational design is significantly different from an operational design. It’s not surprising that most programmers are taught and tend to think in terms of how computations are carried out instead of what computations are needed and the ways we can compose them. I still struggle with it at times. I classify it separately from “indirection,” because of the laws that govern a design process like that. The same rules used in algebra work in programs where you can rely on being able to substitute terms for symbols representing those terms. And algebra seems to have been a rather successful language for manipulating expressions. Where it does break down though is at the edges where we need to interact with run time exceptions, the state of resources external to the process, etc. Even in Haskell you can write your code procedurally if you want. You won’t get the benefits of denotational design but at least you’ll still have a pretty decent type system that helps you with refactoring and extracting “logic” later on into something more understandable and easier to work with.

BobbyTables2 2y ago

Premature Abstraction is a common problem, affecting developers of all ages. Most are too embarrassed to talk about it. Fortunately, there are non-invasive therapies that can reduce the frequency of occurrence.

arendjr 2y ago
xD In all seriousness though, you do hit a great point. The moment you stop being embarrassed about your mistakes and set your ego aside, is the moment that you can truly start learning from those same mistakes. At some point it even becomes the only way you can move forward, unless you want to stay boxed inside a niche of expertise defined by your own self-set boundaries.

gspencley 2y ago

I've been a software eng professionally for 25 years. Have been coding more like 30 - 35. There is a fundamental principal here that I agree with and it surrounds a code smell that Martin Fowler termed "Speculative Generality" in his book "Refactoring." Speculative Generality is when you don't know what will have to change in the future and so you abstract literally everything and make as many things "generic" as you possibly can in the chance that one of those generic abstractions may prove useful. The result is a confusing mess of unnecessary abstractions that adds complexity. However, yet again I find myself staring at a reactionary post. If developers get themselves into trouble through speculative generality, then the answer is clearly "Primitive Obsession" (another code smell identified in "Refactoring") right? Primitive Obsession is the polar opposite of abstraction. It dispenses with the introduction of high-level APIs that make working with code intuitive, and instead insists on working with native primitive types directly. Primitive Obsession often comes from a well meaning initiative to not "abstract prematurely." Why create a "Money" class when you can just store your currency figure in an integer? Why create a "PersonName" class when you can just pass strings around? If you're working in a language that supports classes and functions, why create a class to group common logical operations around a single data structure when you can instead introduce functions even if they take more parameters and could potentially lead to other problems such as "Shotgun Surgery." This is not to say that the author is wrong or that one should embrace "premature abstraction." Only that I see a lot of reactionary thinking in software engineering. Most paradigms that we have today were developed in order to solve a very real problem around complexity at the time. Without understanding what that complexity was, historically, you are doomed to repeat the mistakes that the thinkers at the time were trying to address. And of course, those iterations introduced new problems. Premature Abstraction IS a "foot gun." What software engineers need to remember is that the point of Design Patterns, the point of Abstractions, the point of High-Level languages and API design is to SIMPLIFY. One term we hear a lot, that I have been on the war path against for the past decade or two is "over engineering." As engineers, part of our jobs is to find the simplest solution to a given problem. If, in your inappropriate use of a given design pattern or abstraction, you end up making something unnecessarily complicated, you did not "over engineer" it. You engaged in BAD engineering. When it comes to abstractions, like anything else, the key to gain the experience needed to understand a) why abstractions are useful b) when abstractions can introduce complexity and then apply that to a prediction of what will likely benefit from abstraction because it is something that will be very difficult to change later. All software changes. That's the nature of software and why software exists in the first place. Change is the strength of software but also a source of complexity. The challenge of writing code comes from change management. Being able to identify which areas of your code are going to be very difficult to change later, and to find strategies for facilitating that change. Premature Abstraction throws abstractions at everything, even things that are unlikely to change, without the recognition that doing so makes the code more complex not less. Primitive Obsession says "we can always abstract this later if we need to" when in some situations, that will prove impossible(ex: integrating with and coupling to a 3rd party vendor; a form of "vendor lock-in" through code that is often seen). /stream-of-consciousness-thoughts-on-article

sesm 2y ago

Premature abstraction and premature optimization are just instances of Heffalump Trap pattern.

stretch1414 2y ago

Wonderful write-up. One way I really try to avoid premature abstractions is co-locating code wherever it is used. If you don't try to put everything in a shared lib or utils, you keep the surface area small. Putting a function in the same file (or same folder) makes it clear that it is meant to be used in that folder only. You have to be diligent about your imports though and be sure you don't have some crazy relative paths. Then, if you find yourself with that same function in lots of places in your code, you might have an stumbled upon an abstraction. That's when you put it in the shared lib or utils folder. But maybe not, maybe that abstraction should stay in a nested folder because it is specifically used for a subset of problems. Again, that's to avoid over-abstracting. If you are only using it for 3 use cases that are all within the same parent folder path (just different sub-folders), then only co-locate it as far up in the file tree as is absolutely necessary for keeping the import simple. Again, it requires due diligence, but the compartmentalization of the folder structure feels elegant in its simplicity.

ChrisMarshallNY 2y ago

In my experience, I've always found the devil to be in the [late] details. I have learned (the hard way), that, no matter how far I go down the rabbithole, in architecture, I am never a match for Reality. I. Just. Can't. Plan. For. Everything. I've learned to embrace the suck, so to speak. I admit that I don't know how things will turn out, once I get into the bush, so I try to design flexible architectures. Flexibility sometimes comes as abstractions; forming natural "pivot points," but it can also come from leaving some stuff to be "dealt with later," and segmenting the architecture well enough to allow these to be truly autonomous. That can mean a modular architecture, with whitebox "APIs," between components. People are correct in saying that OO can lead to insane codeballs, but I find that this is usually because someone thought they had something that would work for everything, and slammed into some devilish details, down the road, and didn't want to undo the work they already did. I have learned to be willing to throw out weeks worth of work, if I determine the architecture was a bad bet. It happens a lot less, these days, than it used to. Hurts like hell, but I've found that it is often beneficial to do stuff I don't want to do. A couple of years ago, I threw out an almost-complete app, because it was too far off the beam. The rewrite works great, and has been shipping since January. Anyway, I have my experience, and it often seems to be very different from that of others. I tend to be the one going back into my code, months, or years, after I wrote it, so I've learned to leave stuff that I like; not what someone else says it should be like, or that lets me tick off a square in Buzzword Bingo. My stuff works, ships, and lasts (sometimes, for decades).

yellowapple 2y ago

> /// BAD: This mutates `input`, which may be unexpected by the caller. > [...] > /// GOOD: `input` is preserved and a new object is created for the output. Neither of these are good or bad without knowing their context and understanding their tradeoffs. In particular, sometimes you want to mutate an existing object instead of duplicating it, especially if it's a big object that takes awhile to duplicate.

mrkeen 2y ago
If you don't mutate, you don't need to duplicate.