In the Hero35.com's newsletter, I've stumbled upon this video on AHA Programming, where Kent C. Dodds tries to explain this new principle he created. The minute he starts to code I said "AHA!", but not for the same reason Kent intended. Yes, because I think he missed some more important principles in programming.
First things first, what the heck is AHA Programming?
AHA stands for Avoid Hasty Abstractions, from Kent's blog post we can summarize this way of thinking in two points:
- Prefer duplication over the wrong abstraction
- Optimize for change first
So far seems some good points, maybe out of the ordinary, but I encourage you to read the article or at least watch the video before continuing. Or you can just trust me, I'm not judging you!
In the presentation, Kent is showing an example where there is a frontend application that displays the name of a user in multiple places.
In general thinking a developer builds an abstraction by creating a function, say, getDisplayName(user), so if there is a bug in the behavior you'll fix it once and it repairs everywhere.
Kent brings the case when the client or stakeholders ask you to add the honorific to the name on the profile page. It always happens, it's in the software nature to change in time. The example goes on to the point every place where the name is displayed has different behavior. Kent says at this point a developer tent to don't dismantle the abstraction, instead, prefer to add flag parameters to the function/module/component to accommodate new behaviors.
I can agree that a medium level developer has this type of mindset. I also agree that removing the abstraction is a great choice instead of making a wrong abstraction. But I think the same result can be achieved easily following other old good programming principles.
Let me explain.
I recently read the well-known book on software development Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin - I C. a pattern here! It's quite inspiring, it also helped me to improve the quality of my code significantly and my supervisor noticed! You should totally read it once in your life, maybe not too early in your career: just to see enough of what the real world is made of to better understand what Uncle Bob is pointing out.
You can imagine in this book there are a lot of rules and examples of writing code. A lot. I can say principles wrote there are hard to discredit.
One of the main rules that it came out most frequently is the Single Responsibility Principle, a.k.a. SRP, that states that every module or class should have responsibility for a single part of the functionality provided by the software and that responsibility should be entirely encapsulated by the class, module, or function. Uncle Bob summarize in this sentence: "A class should have only one reason to change."
In the Functions chapter, Martin says that a method should do only a task and avoid flag parameters. If there is an if or a switch create two or more method methods if you can.
So back to the issue presented by Kent: we could address the problem by creating another function named getUserNameWithHonorific, so if after a while the name of the user became different in every place we have different functions and is easier to disassemble the abstractions if we see they're a lot and used only in one place. It's easier because you don't have a huge single function that's hard to understand, instead, you have more functions that explain what they do in the name and made by few lines of code.
Conclusions
Dodds' AHA principle is not wrong, but I think that doesn't add anything new, plus it doesn't simplify the comprehension. You can agree with me that you can't define precisely wrong abstraction, it's open to interpretation. Instead, you can more clearly identify functions or components that have more than one purpose.
I think that the parametrization of software has to stay in the higher levels of abstraction, such as abstract classes of a library, the main component of a frontend widget. Only one main switch and different modules/components that do only one thing, so if a change will come - and it will - you edit only one module or create a new one.
Now tell me what you think. I'll be pleased to discuss it!
Cover photo: taken by me last week in a forest near Corno d'Aquilio
Top comments (5)
In fact, I was thinking the same when he showed the demo.. Besides its easy to write a new function that returns something than modifying the older... But then it's subjective on how closer the newer features resembles the existing feature.
I agree with you.
I think the key is that we should properly use SRP, DRY, and AHA. And don't think that these principles exclude themselves
Great point! Like ancient roman said "Melius abundare quam deficere" (it is better too much than too little)
Dang great point I'm reading clean code now based on this post
Thank you!