In the UK there is a TV show called 'Bits and Bob', it's a show teaching children about engineering through story telling. In one particular episod...
For further actions, you may consider blocking this person and/or reporting abuse
I think it's easy to go in circles with the concept of "future proofing" and definitely see it as over-engineering a lot of the time.
Counter-intuitively I think it can also legitimately harm the future when it really is just over-engineering.
I see future-proofing as making sure to not close the wrong doors at the interface level, and to keep technical debt under control. Nitty gritty code cleaning has some value, but I wouldn't call it future proofing in and of itself.
I think this sums it up better than I could have, thanks Ben.
"Future-proofing" isn't simply "going the extra mile" or "adding random junk". Future-proofing is an attempt to anticipate how others might want to use your code beyond those use-cases you originally wrote it for. How well you "future-proof" depends heavily on how well you anticipate what people are likely to want further from your code. So, like many things, knowing your audience is key.
It's fine to anticipate, but in my book don't actually add those features until the "future" is the present. The thing about the future is that I can change.
I generally consider "future is present" to encompass "things I assume people will be opening tickets for inside the next 6-12 months".
I think "future proofing" code is an idea that appeals to all of us when we are starting out, but it's almost always the wrong thing to do. You don't know what the future brings, and you are adding functionality that's not being used, making it harder to read your code. Chances are, the future that you imagine will never come, and you've added complexity for no good reason.
My personal opinion is that when you see code that's "for future use", delete it.
OH Lord You have so much time in development that you can embed extra maybe code. Sorry I was just caught by surprise because I use extra time for commenting so my not so understandable code, code that isn't as self commenting as I thought it was is more readable. That is so when I get frustrated by the death march and pull a Monte Python ( for you that have not seen the Holy Grail 200 times - RUN AWAY, RUN AWAY) the younger programmers will be able to pick up my code and say yes I can read that. Sorry Adam I come from the early death March era not being critical and I apologize if I have offended. No Really I realy do.
ssndude2/Rick
π€.. no I don't think you read the post as intended. it should describe a journey from over engineering to looking for the simplest solution for the time that is needed. In my spare time yes I develop stuff and yes I do crazy shit that I probably shouldn't but it's my time. Spare time is classified as time at home because I am not free at work. Your comment doesn't make a lot of sense to this post, or perhaps I am the one reading it wrongly.
Yes I can reply to my own post with alacrity I hope.
I am trying to understand how future-proofing would work in today's fast build (scrum) and fast build (Scrum again) work environment. You have your stories that the program management folks pick from for each scrum and they very rarely give you an opportunity to read stories that are not in the current scrum. Even As a lead I was seldom given a look at the whole project, at most a month ahead an I don't believe Future-Proofing for 30 days would add enough value to make it worth while. Even as far down the road as 30 days may seem, we all know how fast code can change and how ideas can change even 30 Days out. You would need to capture current and future requirements and some how freeze them to make it worth while or you would be pulling future code as fast as you were writing now code.
I am afraid that Agile Program Management my well make even the Idea of Future-Proofing obsolete just as it has waterfall and a whole whole host of others.
Have a good day and I hope my attempt with out the sarcasm is of some merit to the conversation.
ssndude2/Rick
Perhaps that is relative to the workplace, we are fairly self governing at Dyson. The team has an awareness of what's coming, we pick our tickets in sessions it's fairly open. I don't have any other experience to compare it to but I suppose agile works differently everywhere.
The underlying supposition about "future proofing" is that one anticipates a future need that is beyond the current one...the question is, is that assessment valid???
The natural growth dimensions of an application are pretty easy to identify and if one future proofs along those vectors then that additional robustness would be useful as the applications problem scope grows...however, if you chose incorrectly you can end up building classes or methods that will never be used (the old days of architects sitting high on a design horse over engineering for "future need" come to mind).
Today there is much less need for this type of engineering...we live in a very user centric and design driven development paradigm...where the data and features required by the users are what drives the constructs in the back end that make that happen...it's vastly more parsimonious and more importantly it TELLS YOU WHERE YOU NEED TO FUTURE PROOF.
The users preferences drive the development of things that satisfy those preferences and nothing else need even be considered as the User is God.
For some developers this reverse of the old ways of doing things may be confusing but it is the way it is...and the way it must be to ensure superfluous code for anticipated future needs that will never be executed ...is never written.
I can fully respect this position, it is one that I share. Thank you for chiming in.
To me, "future-proofing" only means "don't paint yourself into a corner" and doesn't include adding features. Most often, I find that the cases where I wished I'd future-proofed involved unstated assumptions. When I'm future-proofing something, I try to find cases where I'm making assumptions, and either remove those assumptions or document them very well.
A common example is a company with a single-tenant architecture (one account per user), finding themselves in the middle of a large rewrite due to a need for a multi-tenant architecture (multiple accounts per user, such as work + personal).
If you are writing a library, go for it:)
I'm gonna steal that
Over-engineering is very often future-proofing for a future that never happened.