A developer I work with has been at the company for a decade. His argument for that longevity? He says it takes five years for code you wrote to come back and bite you once it needs replacing. This reminder of our role in the half-life of technology is something I find fascinating: what does it mean that we're not futureproof?
Every developer has a legacy system they work with (willingly or otherwise). Likewise, every developer will curse that system daily and point out with glee to newbie developers how awfully-implemented the search feature is; how laughably broken the application looks in Firefox; how many disparate JavaScript libraries are jumbled into the page. But these decisions weren't made by idiots, cobbling together rushed web products. They were made by you – or your peers half a decade ago.
It's a humbling experience to have that realisation, that moment of clarity. To know that your decisions which were once sound, best practice, are today the examples shown to fledgling hackers to scare them into avoiding monolithic codebases or teach them why modular programming is important. But if it takes five years for this process to happen, why bother building things for the future in the first place?
We're taught as software developers to architect our work with an eye on scalability: not just in terms of traffic and speed, but in terms of feature growth and expansion. Every simple problem becomes a complex challenge to solve: it's smart to be multiple steps ahead of what your users want today.
Why bother with any of this? We're building systems trying to anticipate every problem or change and then throwing them all away again a couple of years later. How many projects have you been involved with where the agreed solution is to chuck out the old, legacy code, and start afresh? All those architectural decisions have been learned from, updated, but ultimately dropped. Five years.
The first company I worked for was a small magazine with a dozen staff. The owner had a bit of a tech background and had gone all-out when preparing the company's IT systems. In a dedicated room in the basement there was an enormous server rack complete with multiple RAID setups and copious air conditioning. There was a six-way monitor switch allowing you to view output from any of the machines and a steel cupboard full of cables, accessories and tools.
The office was running Windows 2000. In 2010.
Sometimes it's easier to focus on futureproofing things and building with flexibility in mind than it is to work out what's valuable and how to get there quickly. In practical terms, nobody at that company cared how many redundant disk backups there were, they were annoyed that they were still stuck using IE6.
Do I really believe we should code by the seat of our pants? Perhaps not quite. Anyone can hack together a quick PHP/MySQL fix which solves a problem temporarily, but the skill of analysing the problem domain and being several steps ahead of it is one that takes real practice – and adds real value. But perhaps there's something in the idea of accepting the length of your tech half-life – and embracing it. You're going to be wrong, one day. And that's fine.