Code and Systems Reviews – Do You Do Them?
We’re working through a number of systems to upgrade some processing, address the whole responsive thing and so-on. It amazes me how code and solutions just sort of "accumulate" over the years. Fix this, add that, change this… it all adds up to a lot of potential for areas ripe for updating.
How do you address older systems?
Most of the time, it’s definitely a "if it ain’t broke, don’t fix it thing." I get it though – it’s a big deal and big risk to go back and review code, schemas, approaches to how you’re doing things. If you also consider that your end-users and stakeholders have come to use your systems a certain way, it quickly turns into a very cautious situation where you don’t want to upset the proverbial cart.
But there comes a time where you simply must take a deep breath and dive in. Do you do this? How do you approach it?
I think the most successful of code reviews usually starts with (wait for it) the end – the users. How do they use the systems, and how would they like to use the systems. If you can get them to NOT talk about it in terms of the current systems, but instead what they need, you can start to see where to start looking. From there, you can start moving area-by-area and look for updates, look for opportunities to apply new technologies, update code and enhance the functions.
It’s not an easy road, that’s for sure. But the payoff can be substantial.
How do you approach it?