Technology changes on a daily basis, should your business try to keep up?
Not really, no. Unless the business drives that need for change.
This is a mistake that many (including myself) will do. A new piece of technology comes out, our software needs to be rewritten using it. But what advantage does that bring to our business and to our end-users? In most cases, none.
Instead of spending time switching to newer technologies or updating and re-testing after each of your 250 dependencies release a minor update, that time could be spent on developing and delivering new functionality to be used by your end-users. Really, nobody cares you are running the latest version of Angular if you lack features which your competitors have.
Ok, you might say, but what happens in 3 years time when it becomes necessary to upgrade and you are 10 major versions behind and you have tons of “legacy” code?
First, be proud of what you’ve achieved. The fact that you’ve prioritized your resources properly, means that your business is now driving the change and requires you to upgrade. Without this prioritization, your business might have never taken off, you would still be working in the dark, upgrading between Angular versions without anyone actually using your software.
Second, don’t try to re-write your whole software. This is especially true with web applications. Initially, re-write only the modules for which the upgrade was required. Continue with any new modules or features that you are developing and then, as major changes appear in other modules, decide if it’s worth re-writing and if so, do it.
If it works, don’t fix it
Every change you make introduces risk & so with every update you will have to retest your software. Or alternatively you can just release it in the wild and then watch for fires, that works too, up to a point and it really depends on the situation. You could do so for your own product, owning to the fact that if something happens and you and up losing money it’s your fault, your money. But what happens when you make this change for a client – thinking you’re doing good, but the client hasn’t asked for it and you didn’t care to inform him – and you end up introducing a bug which in turn causes your client to lose money. Exactly. You took a risk for something that your client cannot quantify and it blew in your face.
Justifying the change
Change can be justified. Just make sure you’re not lying to yourself (or your client if you’re working for someone else) for the sake of the new toy. Toys come an go, they are broken, thrown away and then you buy new toys. Think in terms of tools, think about productivity, performance, security. “Reducing risk” is too generic. Have real arguments and numbers to support such a decision.
