Dealing with past developer decisions – keeping up or staying still

We all like shiny new things. The opportunity to adopt the latest and greatest new project, the chance to deploy a service on a different framework, or the ability to take an innovative approach to tracking and managing your work. All these things spark your creativity and get your mind racing. They can lead to fresh innovations and better software. As developers, this is a big part of what drives us.

Fast forward a couple of years. Those new things have hopefully become tried and trusted solutions and are often no longer at the cutting edge. They should have support programmes, enthusiastic communities, and widespread adoption. At the very least, they should be robust and supported implementations that work reliably. However, unfortunately this is not always the case. Old software may fall out of favour, but the cost of supporting it continues.

SEE ALSO: Software development trends: Top tools and methodologies

When we arrive into a new role, we will inherit a number of past technology decisions and find ourselves using products, services, or tools chosen by others. In the past they might have met specific design goals, delivered a chosen piece of functionality to the business, or reflected software architecture assumptions based on previous volumes of users, performance requirements, or data growth predictions. If we are lucky they are recent decisions, but unfortunately we are often stuck with products, services, or tools chosen in the distant past, that have become “the way we do things.”

So, when is the right time to keep running with someone else’s design decisions, and when should you use the metaphorical ‘reset’ button?

Thinking about change

Although we sometimes have the freedom to choose our own path, that is not always the case. Sometimes, there are financial or design choices that we need to respect and work around. At times, the status quo seems to be limiting and arbitrary. To make the right decision, it is worth getting data on the following areas:

• The cost of supporting existing applications
• The time spent running these systems
• The results from staying versus the results from moving

These three elements affect each other, so it is important to consider them in context, based on specific data points.

For existing applications, the cost of licenses and maintenance can be taken for granted by developers, particularly if it is not their budget being used to pay for support. However, terms and conditions can change based on financial decisions that vendors or suppliers might make, and changes in status around particular systems can lead to increased costs. Support contracts often roll up multiple systems into overall bills. These might make it easier to account for, but this method obscures what you are actually paying for.

Over time, this can all quickly accrue to a significant cost. Support for specific applications or components no longer being used by your business are still being charged to the total bill. Unpicking what you use today, compared to what you’ve moved on from is difficult, if not impossible.

When using open source software options, licenses are generally not as much of an issue. However, there may still be external contracts required to support applications, or software components. Access to expertise and advice can be essential in order to keep these services running, so those costs should be factored in.

Time is money

Alongside this, you should consider the amount of time your team spends on support and maintenance. For open source packages, internal team hours may be required to support those packages or installations. These should be included in any cost considerations. Similarly, an older software installation may need more people to manage those regular tasks that keep the service running – for example, database implementations require regular backups. All of these elements should be considered when looking at making any changes. After all, your time is not free.

Finally, it is important to consider what accountants refer to as “the opportunity cost.” Simply put, this involves looking at the cost involved in undertaking a task, and what that money could be used for instead. For example, a new software installation costing thousands may be a good investment, but that same spend could be put into another project which would deliver a higher return on investment.

Spending on project one will require careful consideration if better results can be had elsewhere. This can be applied to existing software. Carrying on with existing tools or products will cost a certain amount, but could a switch to a new service, or updated version, deliver better results overall?

Examining each of these areas can help you to justify sticking with your existing technology, or it could be used to support a much-needed migration project. It is also worth remembering that migration plans alone are not enough – they carry their own risk levels and failure potential. Factoring in risk should be part of any calculations that you make.

Making the decision to move

For developers, it is crucial you consider:

• The cost of licenses and support contracts
• The demand on the team
• The opportunity cost of any changes

By combining these three elements you can work out whether the existing company approach is worth retaining, or if it is indeed time to move on.

If you discover that the potential cost and/or risk are too high to justify an immediate change, it is important to determine exactly why this is. For many projects, a change that replicates existing approaches without adding new functionality can be difficult to justify. In these instances, maintaining previous software products may be necessary until components are no longer supported, or reach its end of life. At this point, it will be easier to justify a move.

SEE ALSO: Can DAST make it in today’s development environment?

For other projects, it can be an opportunity to think longer term. Digital transformation is at risk of becoming a meaningless cliché for many developers, but it can be used as an opportunity to gain support for bigger changes. Wholesale changes to software required as part of a new digital project can be a good opportunity for a ‘clean slate’ approach. However, this approach still needs to meet specific business goals and requirements. Balancing your desire to make software easier to support alongside broader business objectives should be your first priority.

Whatever your situation, basing your overall technology decisions on data is useful, as it makes it easier to justify the decisions you make. Making use of open source can also help. This can make your software development strategy easier, as it avoids most support lock-in costs, and it is easier to bring in the right skills when needed. Most importantly, open source can help you make much-needed changes to the implementation of your organisation’s software, removing the barriers to your success over time.

The post Dealing with past developer decisions – keeping up or staying still appeared first on JAXenter.