Absolutely! Premature optimization is like packing for a trip to Mars when you're just planning a weekend road trip-you'll probably end up hauling a lot of unnecessary baggage and still forget your toothbrush.
There’s a ven diagram between “smart enough to anticipate possible future changes in requirements” and “dumb or inexperienced enough to believe that you can mitigate this proactively”. That said, some futures are worth planning for, if you know they’re coming (or at least very likely to).
That Venn diagram is where optimism goes to die! 😂 But you're spot on-there’s a difference between guessing wildly and making an informed bet on a likely future. Planning for the inevitable? Smart. Trying to outsmart the unknown? That’s how you end up with a Rube Goldberg machine in your codebase.
I think there is a place for future proofing: Knowing you will actually need these abstractions. E.g. you wrote similar code for different clients before and thus have some experience where it will end up. But if you solve a new problem, you dont know what your code has to solve in the future. In this case abstraction is just hubris. You think you know how to describe the world in abstractions. And then the exceptions hit you like a truck.
If you’re basing your abstractions on known patterns or prior experience, it’s not speculative-it’s informed design. The distinction lies in whether you have concrete evidence or are just guessing about future needs. Speculative generality becomes a problem when developers try to anticipate future requirements without sufficient context or data to justify those decisions. This often leads to over-engineered solutions that solve problems no one actually has, making the codebase harder to work with. On the other hand, leveraging prior experience to create abstractions that address recurring patterns is a smart way to future-proof in a controlled, meaningful way. The key is knowing when you’re dealing with a recurring problem versus stepping into the unknown.
I've actually done that. One of our products used to sync through Dropbox, and we moved it to sync via S3. Because of the abstract base class, it was relatively non-invasive. That said, it's not a sure thing that the base class helped. I could just have changed all references from Class A to Class B, and implemented functions until it compiled again. And it was a one-time deal.
@@HollywoodCameraWork If the base class didn't really help then it wasn't done right and didn't need to be done. Sounds like you deal with some strange issues.
I was working on an amateur project for a guy that had already built out a foundation, and his database had like 48 tables in it. MAYBE 5 had data, the rest were for "just in case" and "I need this later." It was a PITA to work in, and that is before getting to the mess in his website that interacted with it. That project made me stop "building ahead" when the Good Idea Fairy would whisper "You might need this later."
I instead like to fully investigate the possible futures, and then just ensure that we're not abjectly working against those futures and preventing them. I'm happy to not build the future until we get there. But ignoring known futures is the road to hell. We're just coming out of a TWO YEAR refactor that was 90% downtime, and it was all from ignoring known futures while writing the code. Totally avoidable. We refused to look far enough into the future, and it cost us 1-2 years of full team downtime.
Wow, two years of refactoring sounds like a tough lesson-I'm sure that’s not an experience you want to repeat! You make a great point about known futures. Ignoring clear signals of where the code might need to go can create massive technical debt and costly downtime, as you've experienced. I also think it’s important to distinguish between speculating on features and knowing about them. Speculation often leads to over-engineering for hypothetical needs, while ignoring concrete, foreseeable changes can have consequences like the ones you described. Your approach of investigating possible futures without overcommitting to them strikes a great balance. It’s about acknowledging likely changes and ensuring you’re not actively working against them while still focusing on solving today’s problems. Thanks for sharing-it’s a valuable perspective and a reminder for everyone to keep their eyes open for those 'known futures' without falling into the trap of speculation.
Simplicity is king. I estimate about 2/3 of code in most codebases isn’t actually needed. I’ve done plenty of refactors where a small amount of code is added and 3-4x the amount of equivalent code is removed.
I was and I still somewhat am guilty of this due to having to work in a context without good internal standards. I realize that my intent, simplifying my future self life, is at odds with the strategy. However I think that many devs do this because they do *recognize* a problem, and they solve said problem with the tool they know best: code. While said problem is best approached from a different angle, getting everybody on board with a style, adding tools to reinforce that style (I don't care where brackets are written, as log as it's consisdent on the whole codebase). Likewise, refactoring and tests should be embraced, but in many companies management is pushing for more features because that's where the money comes from, ignoring the economic aspects of unmaintained code. Teaching to non-technical people that *not* refactoring is *expensive* is a challenge, some don't know and can learn. Some know but don't care because they are already polishing their CV after they get their 'unexpected productivity' bonus.
Thank you for the thoughtful comment! You bring up an excellent point about how developers often default to solving problems with code because that's the toolset they know best. I agree-sometimes, these issues are better addressed through team standards and tools, but that requires organizational buy-in, which isn't always easy to get. In my experience, most products don't even make it to the shelf, so the priority is often building a minimal viable product as quickly as possible. While I don't advocate writing bad code, there are so many great refactoring tools available now that cleaning up the code later isn't as intimidating as it once was. So, for early-stage projects, I recommend focusing on getting the product out the door without worrying about future-proofing. After all, if the product doesn’t succeed, all that extra effort was wasted. That said, explaining this approach to management can be a challenge. I’ve found that construction analogies work well for this. For example, you can compare bad code to poorly placed electrical wiring: it works initially, but if you later need to add plumbing in the same spot, you’ll have to redo the wiring first. This helps non-technical stakeholders understand why cleanups like refactoring are necessary. Finally, when you have these conversations, it’s important to establish your role as the technical expert. A little humor helps: I like to tell management, 'I won’t mess with accounting or marketing if you don’t tell me how to architect software or write code!' It’s lighthearted but gets the point across.
Yes, excellent video. I definitely went through a phase like this in my career. In the last two-three years I have noticed myself finally stepping away from this, and it's much better. However, I think because I wrote (stupid) abstractions, I have learnt how to do it. Many people I know never learned to do it, and now they can't do it. Maybe there is some value in this, although I still feel bad that someone needs to maintain my bad code.
Another thing that can happen is, one developer will be comfortable with a certain level of complexity or abstractness of a design, so it doesn’t feel over engineered to them, so they build a complex solution that handles problems just fine as long as they are maintaining it, but then you bring in more junior developers who need the code to be super easy to comprehend, and they either make a mess or they just can’t touch the “over engineered” code. What makes it over engineered in some cases is the mismatch between the complexity of the solution and the actual developers who will be maintaining it.
Or maybe developers are just used to a different set of design patterns. I think it's key to have a common understanding how code is developed in a dev team. This might change with time but should not change over night.
Ah, the classic 'over-engineered code handoff'-where one dev’s masterpiece is another dev’s nightmare. Complexity is relative, isn’t it? What feels like elegant design to one person might look like a crime scene to someone else. 😂 That’s why shared team standards are so critical. A consistent approach gives everyone a common language to work with, minimizing that ‘what fresh hell is this?’ moment for whoever inherits the code. And yeah, evolving those standards is fine, but doing it overnight? That’s how you give your team whiplash!
Ig this isnt as much the case in game development, say you're making an rpg it would be good to "future proof" say the components/character classes so all new players, enemies, npcs etc. are easy to implement in the future and act consistently
True, in game dev, future-proofing is like setting the rules for a board game before anyone starts playing-it keeps things consistent and makes adding new pieces a breeze. But even then, the trick is to future-proof just enough. Build for expansion, not for every possible DLC idea that might pop into your head at 3 a.m. Otherwise, you’re just creating a boss-level challenge for yourself!
How on Earth is acknowledging the fact that changes eat up the most time cost as well as they're the most difficult part of the design process. How in the world can you say that anticipating this fact and so designing with the idea that the design needs to be flexible enough so that changes won't be difficult. They won't be annoying. The next person that comes in is going to think there's fucking lucky stars that there are already the scaffolding that they need to start making these changes. How is that? Not a good thing? That's what future proofing is. You're not predicting the future. You're using your experience to know with an absolute certainty that people are going to want to change things. A lot of the changes are going to be stupid and beyond that you know what aspects of the design need to be most flexible and so I mean you kind of have I mean that. That's what experience gives you the ability to kind of know what the next person coming in and working on this thing. What are they going to be asked to mess around with first for them to be able to come in and not have to? You know essentially start from scratch as well. You know they're not having to decode something that's impossible to figure out. It's already been made flexible as well as object-oriented enough to where. If they don't like it, it's easy just to remove it all together and replace that something with something else because you've gone ahead and made sure that everything is even modular and even if they don't keep anything, they're still going to work within that modular framework so that that the more people that work on it the less has to be like figured out all over again. And then by the time it makes its way back around to you it's not really an issue. It's already following that flexibility and workflow that you went ahead and provided because you just knew from experience that this is how it works. Maybe design is so different from code, but I can't imagine that coding to anticipate change is a bad thing. I just can't imagine that.
I would say I’m probably the type of developer who tries to implement abstraction and modularity whenever possible. And I can see how this might increase complexity and waste time for both me and my teammates. However, I’ve also experienced difficulties with code that doesn’t have enough structure. I’m talking about hardcoded spaghetti with functions containing 1000+ lines. It was a nightmare to add features when there was no underlying framework whatsoever. Any advice on finding a healthy middle ground?
Great point! Striking the right balance between abstraction and simplicity is like walking a tightrope-lean too far either way, and things get messy. On one hand, too much abstraction can lead to unnecessary complexity that bogs down the whole team. On the other, too little structure turns the codebase into a plate of spaghetti no one wants to touch. My advice? Start simple. Build just enough structure to solve the problem at hand while keeping things flexible for future changes. Use refactoring as your safety net-let the code evolve as the requirements become clearer. And don’t be afraid to involve your teammates in these decisions; shared understanding is the key to maintainable code. Oh, and if a function starts approaching 1000 lines, that’s probably your code tapping you on the shoulder saying, 'Help me, I’m drowning!' 😂 Is getting a refactoring tool an option for you? I'd be curious to see if a good one spots patters.
@theseriouscto I don’t have any experience with refactoring tools, but if you have any recommendations let me know! I finished my internship at the company I was working at, and I’m not sure if it would be an option anyways, but would be nice to know.
It never happens until it happens, before avoiding it you should take into consideration the real project context, the problem that I see with this ideas is that no one suggests a realistic alternative, because yeah you can add noise and unnecessary complexity to the system, but not doing it can also add complexity and bottleneck and the "you can refactor later" in most of the cases it is a very big lie, before taking any decision you should first analyse the context.
The real context will draw a BIG LINE between speculative and the real project context Given that most software projects never get finished, I think it's important to always leave the fluff for later Refactor later is not a lie, it's work Get it working, get it working well, enhance it, repeat
This is a fantastic philosophy that im trying to encourage in our teams. It seems many engineers write complex abstractions for no other reason than enjoying writing code. 😂
Absolutely! It’s like some engineers think they’re composing Shakespeare when they’re really just writing a grocery list. Let’s aim for clarity over complexity!
Why are you attacking me ^^ seriously one thing I want to add - sometimes this overengineering already happens at conception level with bloated requirements that never really get used - because we might need it later
I think I'm attacking everyone ;-) Couldn't agree with you more, hence the power of saying no - OR - priorities. Suits want everything but they have to prioritize and you start with the most important thing. Would a suit get married and fix issues with the bride later? Well we don't write software like that either
Funny comments? Absolutely-future devs deserve to laugh while crying over the code! Just remember, comments are like seasoning: too few, and it’s bland; too many, and you’ve turned your code into a novel. Aim for the sweet spot where they’re useful, hilarious, and don’t double as a stand-up routine.
@@theseriouscto I can only write comments and no code so my opinion doesn't really matter. But as a problem solver, my view is that in the future I'm much more likely to go back to notes to see HOW I was thinking than WHAT I was thinking. In other words, I learn from the process more than from the results. Put another way: the way to future proof code is make it so you're better at coding after every project.
Not intentionally, but I’ll take it if it makes me sound smarter! 😄 The idea does align with Altshuller’s TRIZ philosophy: the best solution is one that eliminates the problem entirely. In coding, that often means solving the problem so elegantly-or questioning whether it needs solving at all-that you don’t end up writing unnecessary code. Truly a case of less is more!
@theseriouscto it's in my email signature "the ideal system is when there is no system" along eith Churchill's exhortation "no idea is so outlandish..." etc.
i'll be pedantic and say that you're really complaining about pre-mature abstraction. Pre-mature abstraction is bad, future proofing is good.. Pre mature abstraction is just future proofing gone wrong.
"Premature optimization is the root of all evil" indeed.
Absolutely! Premature optimization is like packing for a trip to Mars when you're just planning a weekend road trip-you'll probably end up hauling a lot of unnecessary baggage and still forget your toothbrush.
@@theseriouscto Abso-fkn-lutely.
There’s a ven diagram between “smart enough to anticipate possible future changes in requirements” and “dumb or inexperienced enough to believe that you can mitigate this proactively”.
That said, some futures are worth planning for, if you know they’re coming (or at least very likely to).
That Venn diagram is where optimism goes to die! 😂 But you're spot on-there’s a difference between guessing wildly and making an informed bet on a likely future. Planning for the inevitable? Smart. Trying to outsmart the unknown? That’s how you end up with a Rube Goldberg machine in your codebase.
I think there is a place for future proofing: Knowing you will actually need these abstractions. E.g. you wrote similar code for different clients before and thus have some experience where it will end up.
But if you solve a new problem, you dont know what your code has to solve in the future. In this case abstraction is just hubris. You think you know how to describe the world in abstractions. And then the exceptions hit you like a truck.
It's not speculative then
If you’re basing your abstractions on known patterns or prior experience, it’s not speculative-it’s informed design. The distinction lies in whether you have concrete evidence or are just guessing about future needs.
Speculative generality becomes a problem when developers try to anticipate future requirements without sufficient context or data to justify those decisions. This often leads to over-engineered solutions that solve problems no one actually has, making the codebase harder to work with.
On the other hand, leveraging prior experience to create abstractions that address recurring patterns is a smart way to future-proof in a controlled, meaningful way. The key is knowing when you’re dealing with a recurring problem versus stepping into the unknown.
100% true! Abstract base class with interface for data access for, you know, when you might change the DB. Because that happens all the time...
I know right? I can usually debunk that one just by looking at the queries and see if they use specific functions ;-)
@@theseriouscto you have to be prepared. You might get a call in the 3am and you have to change the DB immediately :)
I've actually done that. One of our products used to sync through Dropbox, and we moved it to sync via S3. Because of the abstract base class, it was relatively non-invasive. That said, it's not a sure thing that the base class helped. I could just have changed all references from Class A to Class B, and implemented functions until it compiled again. And it was a one-time deal.
@@ivanmaglica264 Definitely, my DevOps team got those calls from clients all the time
@@HollywoodCameraWork If the base class didn't really help then it wasn't done right and didn't need to be done.
Sounds like you deal with some strange issues.
I was working on an amateur project for a guy that had already built out a foundation, and his database had like 48 tables in it. MAYBE 5 had data, the rest were for "just in case" and "I need this later." It was a PITA to work in, and that is before getting to the mess in his website that interacted with it. That project made me stop "building ahead" when the Good Idea Fairy would whisper "You might need this later."
Ah the classic case of "just in case" tables! Built on the ideology of inspector gadget ;-)
I instead like to fully investigate the possible futures, and then just ensure that we're not abjectly working against those futures and preventing them. I'm happy to not build the future until we get there. But ignoring known futures is the road to hell. We're just coming out of a TWO YEAR refactor that was 90% downtime, and it was all from ignoring known futures while writing the code. Totally avoidable. We refused to look far enough into the future, and it cost us 1-2 years of full team downtime.
Wow, two years of refactoring sounds like a tough lesson-I'm sure that’s not an experience you want to repeat! You make a great point about known futures. Ignoring clear signals of where the code might need to go can create massive technical debt and costly downtime, as you've experienced.
I also think it’s important to distinguish between speculating on features and knowing about them. Speculation often leads to over-engineering for hypothetical needs, while ignoring concrete, foreseeable changes can have consequences like the ones you described.
Your approach of investigating possible futures without overcommitting to them strikes a great balance. It’s about acknowledging likely changes and ensuring you’re not actively working against them while still focusing on solving today’s problems.
Thanks for sharing-it’s a valuable perspective and a reminder for everyone to keep their eyes open for those 'known futures' without falling into the trap of speculation.
Simplicity is king. I estimate about 2/3 of code in most codebases isn’t actually needed. I’ve done plenty of refactors where a small amount of code is added and 3-4x the amount of equivalent code is removed.
I was and I still somewhat am guilty of this due to having to work in a context without good internal standards.
I realize that my intent, simplifying my future self life, is at odds with the strategy.
However I think that many devs do this because they do *recognize* a problem, and they solve said problem with the tool they know best: code.
While said problem is best approached from a different angle, getting everybody on board with a style, adding tools to reinforce that style (I don't care where brackets are written, as log as it's consisdent on the whole codebase).
Likewise, refactoring and tests should be embraced, but in many companies management is pushing for more features because that's where the money comes from, ignoring the economic aspects of unmaintained code.
Teaching to non-technical people that *not* refactoring is *expensive* is a challenge, some don't know and can learn. Some know but don't care because they are already polishing their CV after they get their 'unexpected productivity' bonus.
Thank you for the thoughtful comment! You bring up an excellent point about how developers often default to solving problems with code because that's the toolset they know best. I agree-sometimes, these issues are better addressed through team standards and tools, but that requires organizational buy-in, which isn't always easy to get.
In my experience, most products don't even make it to the shelf, so the priority is often building a minimal viable product as quickly as possible. While I don't advocate writing bad code, there are so many great refactoring tools available now that cleaning up the code later isn't as intimidating as it once was. So, for early-stage projects, I recommend focusing on getting the product out the door without worrying about future-proofing. After all, if the product doesn’t succeed, all that extra effort was wasted.
That said, explaining this approach to management can be a challenge. I’ve found that construction analogies work well for this. For example, you can compare bad code to poorly placed electrical wiring: it works initially, but if you later need to add plumbing in the same spot, you’ll have to redo the wiring first. This helps non-technical stakeholders understand why cleanups like refactoring are necessary.
Finally, when you have these conversations, it’s important to establish your role as the technical expert. A little humor helps: I like to tell management, 'I won’t mess with accounting or marketing if you don’t tell me how to architect software or write code!' It’s lighthearted but gets the point across.
Yes, excellent video. I definitely went through a phase like this in my career. In the last two-three years I have noticed myself finally stepping away from this, and it's much better.
However, I think because I wrote (stupid) abstractions, I have learnt how to do it. Many people I know never learned to do it, and now they can't do it. Maybe there is some value in this, although I still feel bad that someone needs to maintain my bad code.
Maintaining bad code is like cleaning up after a party you didn't throw! At least now you know how to throw a better one next time!
Another thing that can happen is, one developer will be comfortable with a certain level of complexity or abstractness of a design, so it doesn’t feel over engineered to them, so they build a complex solution that handles problems just fine as long as they are maintaining it, but then you bring in more junior developers who need the code to be super easy to comprehend, and they either make a mess or they just can’t touch the “over engineered” code. What makes it over engineered in some cases is the mismatch between the complexity of the solution and the actual developers who will be maintaining it.
Or maybe developers are just used to a different set of design patterns. I think it's key to have a common understanding how code is developed in a dev team. This might change with time but should not change over night.
Ah, the classic 'over-engineered code handoff'-where one dev’s masterpiece is another dev’s nightmare. Complexity is relative, isn’t it? What feels like elegant design to one person might look like a crime scene to someone else. 😂
That’s why shared team standards are so critical. A consistent approach gives everyone a common language to work with, minimizing that ‘what fresh hell is this?’ moment for whoever inherits the code. And yeah, evolving those standards is fine, but doing it overnight? That’s how you give your team whiplash!
Yup - you'll be preparing for anticipated changes that will never be there, while the real changes will anyway require a refactoring
Happy we're on the same page, out of curiosity what content would you suggest?
Ig this isnt as much the case in game development, say you're making an rpg it would be good to "future proof" say the components/character classes so all new players, enemies, npcs etc. are easy to implement in the future and act consistently
True, in game dev, future-proofing is like setting the rules for a board game before anyone starts playing-it keeps things consistent and makes adding new pieces a breeze. But even then, the trick is to future-proof just enough. Build for expansion, not for every possible DLC idea that might pop into your head at 3 a.m. Otherwise, you’re just creating a boss-level challenge for yourself!
How on Earth is acknowledging the fact that changes eat up the most time cost as well as they're the most difficult part of the design process. How in the world can you say that anticipating this fact and so designing with the idea that the design needs to be flexible enough so that changes won't be difficult. They won't be annoying. The next person that comes in is going to think there's fucking lucky stars that there are already the scaffolding that they need to start making these changes. How is that? Not a good thing? That's what future proofing is. You're not predicting the future. You're using your experience to know with an absolute certainty that people are going to want to change things. A lot of the changes are going to be stupid and beyond that you know what aspects of the design need to be most flexible and so I mean you kind of have I mean that. That's what experience gives you the ability to kind of know what the next person coming in and working on this thing. What are they going to be asked to mess around with first for them to be able to come in and not have to? You know essentially start from scratch as well. You know they're not having to decode something that's impossible to figure out. It's already been made flexible as well as object-oriented enough to where. If they don't like it, it's easy just to remove it all together and replace that something with something else because you've gone ahead and made sure that everything is even modular and even if they don't keep anything, they're still going to work within that modular framework so that that the more people that work on it the less has to be like figured out all over again. And then by the time it makes its way back around to you it's not really an issue. It's already following that flexibility and workflow that you went ahead and provided because you just knew from experience that this is how it works.
Maybe design is so different from code, but I can't imagine that coding to anticipate change is a bad thing. I just can't imagine that.
I would say I’m probably the type of developer who tries to implement abstraction and modularity whenever possible. And I can see how this might increase complexity and waste time for both me and my teammates. However, I’ve also experienced difficulties with code that doesn’t have enough structure. I’m talking about hardcoded spaghetti with functions containing 1000+ lines. It was a nightmare to add features when there was no underlying framework whatsoever. Any advice on finding a healthy middle ground?
Great point! Striking the right balance between abstraction and simplicity is like walking a tightrope-lean too far either way, and things get messy.
On one hand, too much abstraction can lead to unnecessary complexity that bogs down the whole team. On the other, too little structure turns the codebase into a plate of spaghetti no one wants to touch.
My advice? Start simple. Build just enough structure to solve the problem at hand while keeping things flexible for future changes. Use refactoring as your safety net-let the code evolve as the requirements become clearer. And don’t be afraid to involve your teammates in these decisions; shared understanding is the key to maintainable code.
Oh, and if a function starts approaching 1000 lines, that’s probably your code tapping you on the shoulder saying, 'Help me, I’m drowning!' 😂
Is getting a refactoring tool an option for you? I'd be curious to see if a good one spots patters.
@theseriouscto I don’t have any experience with refactoring tools, but if you have any recommendations let me know! I finished my internship at the company I was working at, and I’m not sure if it would be an option anyways, but would be nice to know.
@@owenm3112 What tech stack do you use?
It never happens until it happens, before avoiding it you should take into consideration the real project context, the problem that I see with this ideas is that no one suggests a realistic alternative, because yeah you can add noise and unnecessary complexity to the system, but not doing it can also add complexity and bottleneck and the "you can refactor later" in most of the cases it is a very big lie, before taking any decision you should first analyse the context.
The real context will draw a BIG LINE between speculative and the real project context
Given that most software projects never get finished, I think it's important to always leave the fluff for later
Refactor later is not a lie, it's work
Get it working, get it working well, enhance it, repeat
This is a fantastic philosophy that im trying to encourage in our teams. It seems many engineers write complex abstractions for no other reason than enjoying writing code. 😂
Absolutely! It’s like some engineers think they’re composing Shakespeare when they’re really just writing a grocery list. Let’s aim for clarity over complexity!
Why are you attacking me ^^ seriously one thing I want to add - sometimes this overengineering already happens at conception level with bloated requirements that never really get used - because we might need it later
I think I'm attacking everyone ;-)
Couldn't agree with you more, hence the power of saying no - OR - priorities.
Suits want everything but they have to prioritize and you start with the most important thing.
Would a suit get married and fix issues with the bride later? Well we don't write software like that either
That spoiler warning came too late; I couldn't click off the video. :(
So Sorry about that.
Out of curiosity what content would you suggest?
The only future proofing code needs is comments.
Lots and lots of comments. Ideally funny ones.
Funny comments? Absolutely-future devs deserve to laugh while crying over the code! Just remember, comments are like seasoning: too few, and it’s bland; too many, and you’ve turned your code into a novel. Aim for the sweet spot where they’re useful, hilarious, and don’t double as a stand-up routine.
@@theseriouscto I can only write comments and no code so my opinion doesn't really matter.
But as a problem solver, my view is that in the future I'm much more likely to go back to notes to see HOW I was thinking than WHAT I was thinking.
In other words, I learn from the process more than from the results.
Put another way: the way to future proof code is make it so you're better at coding after every project.
@ I have a great video coming up on a comment smell scheduled for Jan 5th
I think you will enjoy the value it will bring
"The best code is the code that doesn't exist", are you paraphrasing Genrich Altshuller?
Not intentionally, but I’ll take it if it makes me sound smarter! 😄 The idea does align with Altshuller’s TRIZ philosophy: the best solution is one that eliminates the problem entirely. In coding, that often means solving the problem so elegantly-or questioning whether it needs solving at all-that you don’t end up writing unnecessary code. Truly a case of less is more!
@theseriouscto it's in my email signature "the ideal system is when there is no system" along eith Churchill's exhortation "no idea is so outlandish..." etc.
i'll be pedantic and say that you're really complaining about pre-mature abstraction. Pre-mature abstraction is bad, future proofing is good.. Pre mature abstraction is just future proofing gone wrong.
We are 100% on the same page, and that's the definition of Speculative Generality. I think the word Speculative gives it away ;-)