In my last blog, I shared what technical debt is and also discussed when to avoid it and when you can leverage it.

Technical Debt is the by-product of a dysfunctional software development process.

In this article, I will try to summarise the red flags to look out for to identify if you are accumulating technical debt. For folks, who have not read the previous blog on technical debt, check it out here.

Red Flags

• Requirements or the scope of work are still not clearly defined.
  Your project owner introduced you to a new project and after the initial discussion asks you to design the software architecture, but the scope of the work is not clearly defined. This lack of clarity is going to create a sub-optimal design and it is accruing technical debt. This process is acceptable to get a jump start on a project or to create a proof-of-concept, but sooner or later you will need to refactor the code.

• Tightly coupled components - too many dependencies between functions, and functions are not modular.

  Your software architecture is too dense and it is difficult to isolate the responsibilities of different modules and functions. Whenever you are asked to implement a new feature, you end up modifying a whole lot of code because of this dependency. This is a clear indication that your codebase is due for refactoring.

• Lack of testing or test suites - Manual testing can be time-consuming and can be prone to human errors.
  When you are part of an organization (or startup) that does not have a dedicated testing team, it often falls on the team lead (or delivery head) to ensure quality software is being shipped to the end user. When the user base of the tool is within the organization, this is still manageable, but it is still a burden on the team lead to guarantee all the critical paths in the software work, and that no new software bugs are introduced. If your team doesn't believe in writing testable code or incorporating automation testing, the entire project is like a house of cards and you are headed for sleepless nights.
  It is a good point to stop and negotiate and/or educate the team on making the code testable and incorporating testing strategies into your development.

• Lack of software documentation - Nobody knows why certain things are done the way they are.
  Documentation is important, enough said. You should spend effort and time maintaining documents on software architectures, software processes, and software requirements. Requirements evolve and people working on the project change over time too. Sometimes the software processes like deployment guides, migration guides, and version control guides also must be documented to ensure the team is aware of the best practices. I would quote from the Zen of Python: Explicit is better than implicit. Ensure best practices are taught to the team and you don't expect them to just know without training.

• Lack of collaboration - knowledge is not shared around the organization and the juniors are not properly mentored.
  Amidst all the project meetings, standups, and retrospectives, we often forget to have a conversation about what interesting things you read on Hashnode or other platforms. Have open discussions with the team. When you are brainstorming strategies and requirements, encourage the team to talk. This will instill a sense of belonging and ownership in the team.

• Last-minute specification changes
  This is a pet peeve of mine. When you do not document the requirements and fail to get a sign-off, you are probably going to end up implementing something different than the person at the receiving end wanted. And sometimes, your product owner wants to wiggle in some last-minute changes. Just be aware of the technical debt accrual and remember to weed them out in a later sprint cycle.

• Poor technological leadership - when the leadership team creates frameworks that are not comprehensive or thought through.
  The software architect might have created an internal framework for the project based on the initial requirements, but if your software team is not flexible enough to refactor the framework as requirements evolve and change. You are carrying the baggage and creating workarounds.

  Another red flag to look for is when you are trying to bring improvements to the framework but the leadership constantly dismisses you. If they are not open to communication and collaboration, then it is a major red flag.

• Lack of knowledge - The developers don't know how to write elegant code.
  Elegant code, this is a subjective and touchy subject. I am not just telling about the variable naming conventions, folder structures, and Pythonic or Javascript way of doing it. If your software team is not experienced enough in that particular technology, or if they are creating tightly coupled systems. You are heading towards a scenario where you will need to refactor the code sooner or later.

Technical debt is a hidden cost that robs your business of its ability to be nimble and make needed changes for your customers. Look out for the above red flags and take action if you see your project is headed that way.