A frequent but toxic approach to system design you will frequently hear parroted by MOST non technical business people and a disturbingly large number of technical people is 'future proofing design' or 'designing for the future'
Future proofing your software is not actually one of the available options, not until time travel gives us a definitive window into the future and even then, attempting to future proof your software would still not be a very good idea/approach.
The reality is that your needs today will be different from your needs tomorrow. Given this reality, you are faced with either designing a system today that's most optimal for today's needs or have a system toady that's most optimal for tomorrow's needs, but suboptimal for today's needs. What you can't do is design a system today that's optimal for both today and tomorrow, and attempting to do so only lands with you with the third option - a system that's suboptimal for both today and tomorrow's needs. This is what attempts at future proofing ultimately get you.
Future proofing is a sentiment expressed by people with the wrong disposition. A disposition that has already resigned itself to the 'fact' that the engineering team is unable to effectively change and adapt software, which is kind of absurd considering making changes is quite literally what engineers do.
The correct approach is to build a culture that isn't resistant to change, but rather one that embraces it early and often. A culture that frequently and comprehensively re-evaluates the current system vs business needs and sees what needs refactoring and re-architecting. A culture that keeps track of fundamental assumptions made and when evolving business needs inevitably violate said assumptions, lean into this change and happily pay the price of making the necessary architectural changes to the system required to accommodate the new world, rather than hacking together some Frankenstein monster that puts your organization's system on a path to irrelevancy (the dreaded re-write).
A frequent but toxic approach to system design you will frequently hear parroted by MOST non technical business people and a disturbingly la...
I recently had a discussion about about whether or not people should test private methods. One of my colleagues exclaimed that the problem w...
I've been a tech lead for several years now, and I'm often asked (at interviews or general discussions) about my leadership philosop...