Tech debt is all something I think we have experienced. While we all aim to not add technical debt to what we maintain, sometimes it is inevitable. While it may be inevitable, there are things we can actively do to better reduce and mitigate it. Last month Appfire and I had the privilege of holding a breakout session at the Atlassian Unleash event on this very topic, so let’s get going!

what is tech debt?

This is something we have all heard time and time again. In a nutshell it can come from anything and anywhere and is when we are in deficit to our work. It is the process of building reliance on people, skills, code languages, apps and is anything we spend more time maintaining then what we get back in use. Tech debt is anything where there is increased risk of something going wrong.

Some of you may have seen the “is the jar full” story on social media, with the ping pong balls, pebbles, sand & water. If you fill your jar with large complex items, you limit the availability and resource to manage smaller and easier things. Now imagine your Atlassian environment is the glass jar. Every action you do has a cost. Some will be so minute that it won’t matter. Some will be simple changes to update already previously spent actions. But your jar is only so big and with every action does come responsibility to maintain it for the future. The more complexity you build, the harder things can become to maintain and the more of your jar is filled. You only have so much of a finite resource to look after your ecosystem.

Why does it matter you may ask?

1 - A recent McKenzie survey’ results showed engineers were able to reduce time from 75% to 25%. All the extra time can be spent delivering functionality your end users want or creating performance improvements etc. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity

2 - Having a modern environment with less legacy items to maintain also makes the application attractive to users to work in and for the admins to look after. Helping you keep employees happy and not carry unnecessary stress in already busy working lives.

3 - Tech debt is known to be a lead cause of friction within systems, so having a lean system is beneficial.

4 - The less tech debt, the less risk their is for things going wrong as a whole. The more the company can feel comfortable that internal business critical applications are going to stay healthy & helpful to employees over hindering them.

what can we do to mitigate against it?

Reduce wherever possible.

Reducing tech debt is an essential task that businesses need to take seriously. You wouldn't continue to build a house on unstable foundations, so why do we expect solutions to work any different?

proactively scan your environments.

MAKE TIME to look through your code or your applications and find where there is tech debt. Now you have found it, don't just ignore it. FIX IT! Developers are encouraged to scan code to find weaknesses and debt. The applications we use should be no different.

Re-write scripts with no code / low code alternatives.

Automating is still an essential task and one I would encourage, but can we find more (tech debt) cost effective ways of doing them? Low / no code solutions exist out there. They provide us an opportunity to reduce the debt by having the opportunity of additional users managing those automations as it does not require knowing coding languages.

Reuse config and create standards.

A lot of projects within Jira may be very similar in use. Wherever we have similarly used project, try to create a 'standard' so we can re use any of the schemes. It makes the projects easier to manage. If you find that a project then needs to break away, you can create specifics at this point rather then starting immediately with them.

Sharing config between projects also helps with an easy transition between the projects for the users as they are not having to understand a change in process or the data that should be present on issues.

Train your staff on best practices

Training is a problem that I think every business suffers with, without meaning to. Spending the time helping them understand what best practices are, and why we try to follow them is an important step in reducing tech debt from occurring in the first place.

Finding a good support network

“Every coach needs a coach”. We cannot be expected to know everything or cope with everything alone. We are all human. Sometimes we just need a helping hand to ask questions or check we are on the right lines. Finding these support networks is a crucial step in relieving the burden on individuals on always having to know best practice. That good shoulder to lean on is important.

How can automation help

Automation is incredibly important in this day and age need to always be looking to make ourselves and our team more efficient. Automation is a great way to do this. With the rising popularity of low/no code automation platforms, it is not a surprise why. Gartner projected that in 2021, no code automation brought a 23% increase in productivity.

Low/no code automation rules can massively help us in our mission to reduce our debt footprint. Writing rules in this fashion can help reduce the reliance on individuals since you no longer require the ability to read and write specific code languages. With rules being written in a when if then that statement, business users can feel more included in both following and understanding the rule but also in maintaining their own rules. While the rules are easier to understand, an important factor is that that are just as equally powerful automation engines like the native Jira automation platflorm A4J, is an incredibly feature rich platform allowing almost any use case to be written in it.

The native Jira platform can also be actioned by project admins, an additional pro is that there is less reliance on only admins being able to maintain those rules. With more opportunities for more individuals to write and maintain their rules, teams can become more self sufficient causing less requests for the admins and allowing work to be completed faster.

While you may consider automation rules extending technical debt, you have to remember that the debt is inclusive of the individuals time to maintain and dependencies as well as the rule itself. Automation in general can definitely add to the tech debt. No argument there, but the thing to bear in mind, is to build with scale in mind. Think about how your rule may need to change as the scope changes. Having a more flexible rule will give you a lower debt rule.

Things to remember

you are in control

As the admin you are in control. If you feel that requests will bring a level of complexity that could create unmaintainable debt, you have the obligation to say NO! You have to think both about the system as a whole and the other users that could be affected. Work with the requester to find a suitable compromise where they get as close to the functionality they need while having something that is scalable.

Automate

Automation is key. We need to do it and I do not want to put anyone off of it. You just have to think about the design of the rule. How can we scale it? Who will maintain it?

Bespoke v maintenance

Does this project look or work like others? Can we re use and reduce the need for bespoke config every time. There is no problem making the application work for us IT HAS TO. But we need to make sure that wherever we can we think to the future.

Check out the video