What strategy is best for your organisation to take for modernising legacy applications? In this post, we introduce 3 strategies, their benefits, and issues you may encounter.
More people are now being forced into a remote working lifestyle that they may be unprepared for. I’ve been a mostly remote worker for around two years and wanted to share some of my routine in the hope that some may find it helpful.
At Made Tech, our company mission is “to improve software delivery in every organisation” and recently while using Azure DevOps, I’ve been feeling that currently, these two things are mutually exclusive.
It can be scary to devolve a lot of managerial and planning responsibility to teams but we’ve found lots of positives in changing the way we approach time management. Allowing teams the ability to plan their workloads, holidays, working location and client engagement has resulted in a greater sense of ownership on projects.
I hate public speaking. It’s one of those things that I avoid at all costs. Though when my Brother made me his best man, there was no getting out of delivering a speech. And when my colleague signed me up to a do a talk without my consent (thanks Chris!), there was no getting out of delivering a tech talk.
After you have mapped your application ecosystem as best as you can, you should begin work on prioritising which applications to modernise first.
Just as digital service teams are measuring the performance of their products, it’s important also for technology departments and development teams to decide on what good technology looks like so that we can ensure the choices and practices we’re implementing are having a positive outcome for our users.
For the last year or so, the majority of our new projects at Made Tech have used Ansible as our go-to tool for provisioning and configuring our servers with the software that runs on them. We’ve paired Terraform with Ansible and Chef previously for creating our cloud resources, but have recently been experimenting with using Ansible to see if the one tool was capable of both of these stages in our infrastructure setups. We’ve not been disappointed with our experiences so far.
As developers we always appreciate a second pair of eyes and an extra brain. The eyes are really helpful for catching that extra whitespace you might have missed. The additional brain power might help you solve a problem in your code with 5 fewer lines. All of this results in better code and more collaboration.
Over the past year I’ve worked on a number of projects that have involved some large organisations. By large organisations, I mean, big hefty things that have been around for a while, have lots of cogs and yet still achieve a lot.