1. Blog
    2. The Art of Tech Debt

    The Art of Tech Debt

    Credit: 3back agile methodology & Jeff Atwood

    • Technical Debt is a fantastic concept developed by Ward Cunningham in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.  You can think of the concept as doing things the quick and dirty way which in the long run sets up the solution to have ongoing technical debt, which over time will come in the form of extra effort that is required in future development.The concept also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. The all too common problem is that development organisations let their debt get out of control and spend most of their future development paying for this.

      So what architectural design ideas would help to minimize the accrual of technical debt? Perhaps a modular approach to adding future functionality, like snapping on Lego blocks approach?

      To date there hasn’t been a software development project that I’ve participated in that hasn’t accrued technical debt.

      To change code easily, developers need to understand what they are actually looking at so they can find what needs to be changed.  To allows them to produce and maintain Clean Code, it is necessary to do continuous clean-up, known as Refactoring. The key word here is ‘continuous’ – not ‘every once in awhile.’ The code itself can’t tell you what design decisions were made and why they were made. It can’t tell you what the logical groupings of entities into modules are.  At the very least, there should be comments embedded in the code to help developers understand what is going on.

      Experience shows us that once the amount of dirty code gets too big, it is very hard to clean it all up. Test Driven Development, Coverage Testing and Refactoring are intricately linked.

      We need to ensure that our customers are aware of their Technical Debt and the long term cost of carrying this debt has on their solution.  We need to deal with both legacy and new code and you shouldn’t be afraid to rewrite code. It can be scary to do so, but the benefits can be huge. Even if the end result isn’t any better, you at least didn’t blindly leave it as a mess and will have a better understanding. Try to rotate the refactoring amongst your developers on the team, they then start to understand the pain of not originally being willing to rewrite code.

  • Summer 2019 Release Notes

    With the recent Summer 19 Salesforce now fully deployed in Production orgs, we’ve picked a few key highlights we’d like to bring to your attention.

    Learn More

  • The Most Important Salesforce Terminology You Should Know

    Salesforce terminology follows its own original style which could throw new users off a bit when trying to find their way around the terms. To make things a little bit easier we at SalesFix have put together a list of more commonly used terms

    Learn More

  • Best Practices for Deleting and Maintaining Salesforce Data

    The Salesforce CRM is an excellent resource for businesses to keep a record of client data and use that data effectively. However, it is important that Salesforce data be reviewed occasionally and kept up to date. Doing this can be time-consuming, and if not done systematically, can result in prolonged downtime. Here we discuss the best practices for deleting and maintaining Salesforce data so that the process is quicker, more efficient and with fewer to no errors.

    Learn More