How do you manage technical debt in mobile apps?

Applying linting – especially with "fix on save" –?will help a long way to align a team and codebase on certain standards. In most projects, shortcuts will be made at some point. Make note of it, add a TODO in the project and ensure TODO's are easily visible. Strive to keep the list of warnings and TODO's to an absolute minimum, preferably 0. This will make any new issue immediately visible, instead of losing track of it between all others. Apply the "Boy Scout Rule" (leave the code better than you found it) to do frequent, small improvements and refactorings, instead of allowing technical debt to accumulate.

From my experience, On the static code analysis, you should pay attention to the Lint warnings. It’s a common practice in all the technologies, be it web, Backend or mobile apps development. One should pay attention to the lint warnings while coding. To make the static code analysis automated, there are various tools available, you can integrate that with the source code management tool you are using for the code management. There are static code analysis tools available like SonarQube, Codebeat, Codacy, etc. Having it integrated for each Pull Requests, it will bring tech team’s attention to every single line of contribution.

Completely agree with the suggestions here. Sometimes the company will be hesitant to make changes as it might impact their existing user experience or business. But as developers its our duty to let them know that building features on top of a porous code base that has accumulated tech refactoring is very dangerous and it can all affect everything concurrently.

Using tools such as swiftlint can identify critical issues, code smells automatically with every build and tools like swiftformat even help fixing them automatically with a single command - the changes can then be reviewed and adopted.

"Prioritize" is the key here. Though Technical Debt is detrimental and causes issues in the long run, it can also be a strategic choice. Startups, for instance, can decide to intentionally accumulate Technical Debt to shorten the time-to-market for their product. By fostering a culture of open dialogue between Developers and Business Stakeholders, teams can make informed decisions about when to take on technical debt and when to prioritize actual feature development. Once Technical Debt is prioritized in the backlog, regularly scheduled "tech debt days" or "refactoring sprints" can be a proactive approach to address accumulated debt without waiting for it to become a bigger issue.

As I mentioned in my previous note above, the team should utilize specific automated static code analysis tools, along with manual code review practices, because the machine follows the algorithm and can get you many insightful dashboards. In regards to allocating time for tech debt management, it ultimately depends on the sprint planning, team allocation, availability, features expectations from the client side, and priority levels. However, the tech leads and engineering managers should allocate some time to managing tech debts on a time-to-time basis.

I agree with this but the challenge is prioritizing this against the revenue generating features is difficult. Leaders have to provide guidance and guardrails to incentivize both shiny new features and constantly improving the existing code base.

Unfortunately a lot of companies don't understand the seriousness of accumulating tech debt. Most of the projects that i have worked on have a lot of legacy code written 6 years ago and have never been refactored to use any of the latest practices. Earlier, Google never forced developers to make changes in implementation. But right now with Android 13, a lot of APIs have been either deprecated or the underlying implementations have changed leading to unexpected crashes. Also in many companies the Android platform is never taken seriously unlike iOS where apple forces developers to keep things upto date.

In the real world, we often find ourselves constrained by limited time and resources. Our attention must extend beyond technical debt alone, as we must also deliver new features, engage in planning, attend meetings, and implement tests, among other tasks. Consequently, it's quite common for technical debt to be neglected, and regrettably, this is far from ideal. The optimal solution lies in striking the right balance between maintaining a steady delivery pace and giving due attention to resolving technical debt. Neglecting technical debt is not a viable option, as doing so would inevitably erode the quality of our codebase. Furthermore, some of these unresolved issues could escalate into significant problems in the future.

I consider technical debt to be of utmost importance when aiming to enhance your product using the latest tools and technologies. In certain instances, teams fail to acknowledge its significance or allocate it a lower priority. Occasionally, even when the technical team highlights the gravity of technical debt, it is overlooked, resulting in performance issues. Allocating resources and time to address technical debt is a crucial step toward maintaining a robust codebase and delivering a superior product.

"Technical debt" is a euphemism for "bad design" -- it is better to avoid it in the first place rather than try to pay it down later. The best way to avoid technical debt is to design the app carefully in the beginning, specifically data architecture and user experience (which are closely related). Don't skip the painful stuff, like error recovery, retry, undo, and data entry parsing.

Documentation is key here. Ensure that any contributor to the project can find their way in the project in terms of structuring, methodology, architecture etc. Have a good README that can direct the reader to certain parts of the project for examples or further documentation. Include diagrams for architecture and keep them up-to-date. As for writing code that aligns with the project, using templates, code snippets or code generation can also help a lot to ensure contributors stick to the same approach. Invest some time in setting up such snippets/code-gen; it might take some time but will definitely pay off in the long run.

We are all learning while building a new app and we often look at our old code and think of how badly it was written. Revisiting and refactoring might seem very painful but it does give immense satisfaction to improve something and make a better version of it yourself. We might also end up making frameworks that are good and can be used by others - these modules could be separated out from the app and published or even patented. For example a really good filter framework or a good timeline that can be integrated into any app.

Process plays an important role in reducing tech debt. Learn from the mistakes and improve that step or stage. Leveraging tools is another way to keep the process consistent and repeatable. Tools are part of testing and need to be levered from the development activities. Shift in the paradigm for developers, who should focus on the requirements and test to achieve the final goal. The test should be repeatable and automated.

In most companies, this really depends on the nature and practices of the former developers. Most companies have the habit of outsourcing projects and the developers who work on these projects are newbies and due to time constraint, they write codes with no structure or architecture. At the end of the day, everyone is just trying to make the application work but nobody cares about readability and maintainability. So definitely at some point developers have to raise a concern and buy time to do tech debt

Managing technical debt isn't a one-time activity but an ongoing process. The software development landscape is dynamic, with changing requirements, evolving technologies, and varying user expectations. It's essential to consider technical debt as a living entity, continuously growing and shifting. Monitoring and measuring it allows teams to be proactive, tackling issues head-on before they magnify. Just as consistent health check-ups lead to longer life expectancy and better quality of life, regular evaluation of technical debt ensures the longevity and reliability of software applications. By keeping a close eye on these metrics, organizations can ensure that they're not just building software, but they're building sustainable software.

In my experience measuring technical debt in terms of how much it is reduced is a game of chasing ones tail. Often it becomes amd exercise of filling time. Understanding the value of technical debt, and how it relates to real metrics like performance, and measuring those metrics and the technical debt that was the cause is a far better and more manageable approach. This ultimately empowers developers and changes mindsets to from “fix problems” to create solutions. I made the app faster as opposed to I fixed something that made it slow. Studies have shown that positive reinforcement works better on performance than negative feedback, so attaching technical to problem solving can be utilized as a form of “giving wins” to a developer.

In software development, measuring and monitoring technical debt is much like steering a ship through the tides. The team should be correcting the ship's course whenever it is evident it will steer in the wrong direction. A little too much, and the ship will sink. On the other end of the spectrum, specialized tools become indispensable when dealing with extreme cases. In iOS development, for instance, it's crucial to look into Xcode Instruments to predict the application's behavior. This helps safeguard against catastrophic scenarios on a live environment, ensuring a smooth and reliable user experience.

The adage "if you can't measure it, you can't manage it" is particularly relevant here. It's crucial to link technical metrics to business objectives. This linkage helps in demonstrating the business impact of technical debt and securing the necessary support and resources for its reduction.

By identifying the root causes, whether they are process-related, skill gaps, or resource constraints, we can take targeted actions to prevent similar issues in the future. Retrospectives, especially, are valuable in a startup environment as they encourage a culture of continuous improvement and collective responsibility.

Addressing technical debt is more than just a technical exercise. It is also a cultural and mindset shift. By institutionalizing a culture of learning from past mistakes and continuously striving for improvement, organizations can ensure not only the health of their current projects but also lay the foundation for the success of future endeavors. Embracing this iterative and reflective approach to development ensures that technical debt, instead of being a looming threat, becomes a valuable lesson in the journey of software creation.

On top of this code monitoring automation can be preprogrammed with watch out for learned types of technical debt. With more sophisticated AI tools that understand code and structure this is becoming a much easier task to accomplish. This type of solution can warn developers when they are unknowingly creating new technical debt that looks like old technical debt.

It's essential to reflect on past projects, document the debt encountered, and conduct thorough post sessions with the team. Also, step up communication with management, and ensure that before establishing goals and features on an ever-changing project, a meeting plan should be presented to at *least* the Mobile Development team Lead, where elaborate feedback should be taken into account for finalizing propositions.

I’m missing a good CI or continuous integration tool. Once you have all techniques in place, just forget about them. Make sure the whole process is automated and your team focused on what matters, producing good software

At its core, the need to communicate and collaborate on technical debt is about ensuring alignment. It's about making sure that everyone in the company, from the developer to the CEO, understands the significance of technical debt and is on the same page regarding its management. In many ways, technical debt is like an iceberg. Stakeholders might only see the tip – the manifested bugs or delayed releases. However, beneath the surface lies a larger mass of intertwined challenges. By effectively communicating, teams can ensure that stakeholders don't just see the tip but understand the entire iceberg.

Educating business about the need to work better is the first thing to do in the project. Otherwise technical debt elimination will happen in secret and will create intrigues and politics even amongst the programmers. Unfortunately, the business at all levels will start understanding the programmers only after few bancrypcies. Alternative would be to get the business owners to meet with bancrypt ones in some special experience sharing business clubs. Inclusion in our world leads to various people getting in business. In many cases only fear stories or personal experience will create necessary understanding. Technical debt mainly exists because of the management.

Quality should always come first, it might be a difficult conversation to have with the ever growing demands of the customer but the features can wait. Writing unit tests and fixing code smells should be taken seriously to keep app stable in the long run.

Actually, this should be strep 0. Before anything even starts, you need the stakeholders to be on board. You are going to spend a lot of time on things that are not going to produce immediate results, so you better have them backing you up when your velocity shows down a little bit while you start fixing things

Switching ownership of a software module. On occasion, you may overlook the evaluation of code that falls under your ownership as a developer. Having a fresh perspective from another team member can be insightful. This practice benefits both by improving team comprehension and ensuring code quality. The new owner is responsible for optimizing and reevaluating the existing logic. As time goes on, certain logic might become less effective, or new approaches for handling complexity could arise. When considering refactoring, it's important to assess the potential impact. Allocate some buffer time within your sprint to accomplish such tasks, and consider recognizing milestones in code improvement with awards.

Just like monetary debt, technical debt isn't necessarily a bad thing if it's the result of a conscious decision / strategy, and there's a clear understanding of the cost. For example, early stage startups may quickly pull something together knowing it's fragile because they want to test the value proposition before investing heavily in creating a robust product. However, accidentally slipping into technical debt should be avoided as much as possible in the short term. I actually think it's almost impossible to avoid technical debt in the long term because it's near impossible to predict what infrastructure a business will need in 5-10 years time.

In my experience there are three steps to tackle tech debt in mobile apps (or any system). 1. Decide when you want to pay the tech debt: Most orgs don't give this enough thought. The best time to pay down debt is in a product down cycle, or post-funding. 2. Communication nature and impact: Transparency to all stakeholders is key. Be brutally honest as to the impact and nature of tech debt. 3. Automate the Mundane: Automating the mundane buys you time to think through the bigger tech debt items and reduces precious engineer time from needless firefighting.

Technical must treated as delayed work, as such technical debt must go into your backlog as soon as they are incurred. This way the team acknowledges technical debts for what they really are.