It’s a common problem, there’s a young kid on your team who thinks he is a great architect. He wants to replace the simplest include with a new whizbang inherited menu system or add 3 layers of abstraction to the database access layer, or replace the beautifully crafted error reporting system with exceptions. When quizzing this “architect” he has a reason for every possible change, these are those classic excuses and reason.
1. Security. “This will stop any possible security breaches in the future,” he says. Little does he realise that including one extra file into your system isn’t a security risk and probably never will be.
2. Performance. “We will do this and this and this, and then cache it all in memory. It will be faster than the existing system,” he says. Sure this might be faster, but the difference between 5ms execution and 8ms execution is irrelevant. Chances of him actually having done the profiling and being able to improve the performance gains are minimal.
3. Future proofing. “This will put us in a great position to make changes in the future.” Which changes? You know those unspecified, unrealised and unkown changes that we may or may make sometime in the future.
4. Outdated. “There’s a new better way to do that exact thing.” There is a new way to do it, there is a new way to do anything and everything, but is it better? Is it worth holding the project back a week to modernise the codebase? Probably not.
5. That’s ugly. “But this code is ugly”, he pleads. Is a 3 line hack better or worse than a leaky abstraction?
I’m sure you know of more, what are they?