This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
"duplication is far cheaper than the wrong abstraction."
"duplication is far cheaper than the wrong abstraction."
Most engineers seem to have the wrong takeaway from this post. Every abstraction goes from right to wrong eventually. The answer is not to not abstract, the answer is to ruthlessly tear down abstractions when they go from right to wrong, which people seem to have trouble doing.
I think the other major problem with abstractions is that they have a cost and no one seems to like to discuss that. Even the right abstraction has a cost.
1. Write _anything_ that works. Dependencies, code quality don't matter. Code is idiosyncratic but can be understood by a reviewer.
2. Apply abstractions _everywhere_. Re-implement data structures and algorithms (maybe unknowingly). Code is now very hard to understand.
3. Figure out one is completely unable to update or even maintain code written 6 months ago. Rewritten code suddenly becomes clearer, one begins to think about programming as an craft and not just hacking things on a keyboard until you get the desired result. Dependencies, judicious comments, code quality and a sane terseness become important. The journey starts here.
Personally, step 1 was very short as I learned to program on the job. I was responsible for code, and so I needed to get it together quick. A language like Python makes 2 very easy, and 3 came very quickly too since, as I mentioned, I was responsible for the code (one man team).
I have met people who work at large institutions who are stuck at 1. Others with degrees in CS who are stuck at 2. Some just "get it" and go straight to 3. But typically, the real journey starts when you need to go on with work but your prior self is preventing you from being efficient. You need to get rid of that prior self's work to move on.
"hey we need feature X" (feature X is 2 lines of code).
"Ok, I've made 4 layers of abstraction, and 2 interfaces! an extra abstract class!"
If you treat the new way as an experiment, and only gradually convert the rest of the code, you're in for a smoother ride.
It's totally fine to try out an experiment in a branch and deploy to QA but don't deploy it to prod until you're sure.
This comes from a lack of discipline in the org, not from the parent's (IMO) correct guidance that an org should undertake architectural changes with pilots in isolated parts of the code base.
I think this is a journey a lot of software engineers go through. I can say I was walking down this path in the past.