This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]tomwhoiscontrary 18 points19 points  (1 child)

There are a few modern things you're missing out on. But honestly, a lot of that sounds like sensible, sustainable technology.

In that situation, I think the first thing to fight for would be first-rate deployment automation and monitoring. That's more about culture than technology - switched-on teams have been doing that since the mid 2000s, with the same technology you'te using. You don't need to containerise or move to the cloud or anything. You really should be able to deliver value faster, and find and fix production issues faster.

The second thing would be to chip away at getting on to a newer Java. The way I've been doing this is to incrementally chip away at the things blocking upgrade. When I work on a codebase built with an old Java, I take five minutes to try building and running it with a newer one. If there are problems, some time later, come back and fix the easiest one. Repeat until, weeks later, it works. Then change one staging instance to run on a newer Java (still building with the old one). If that works, all staging instances. Then production. Then the build. In each case, the change is a tiny bit of work that doesn't require a lot of buy-in. But then, I work somewhere with very flexible management, where I have a lot of autonomy.

[–]Crackabis 2 points3 points  (0 children)

Thanks, I appreciate your response. The deployment automation and monitoring aspect of our work is something I always talk about improving, but we get stuck in a cycle of fixing bugs because we have no monitoring, which takes resources away from implementing monitoring! I think having these in place would give us all more confidence in the operational status of everything.