Reduce Technical Debt

Reducing technical debt is an integral aspect of refactoring. Here are the signs to watch out for:

  1. Service contracts are modeled for a specific consumer, and/or exposes technical implementation details (e.g. service interfaces that force the client to set ‘default’ values on legacy system attributes).

  2. New clients are integrated to services without doing performance testing – this increases the likelihood of sudden spike in volume and consequently the risk of breaching SLAs

  3. Each service is implemented using an ad-hoc set of technologies, design patterns, and idioms – if you are starting to see the same functionality over and over being implemented across modules that’s a sure sign!

  4. Service dependencies are not captured and managed – each service uses a rat’s nest of dependencies causing classpath conflicts and maintenance burden when updating versions.

  5. Deployments are manual – binaries and configurations are assembled and made available via manual steps – automated deployment scripts either don’t exist or they are out of date

  6. Exceptions are not handled consistently – depending on the nature of the exception your service might need manual support intervention, adjustment to resources, and/or targeted alerts.

  7. Services are not reusing business object definitions and introduce redundant definitions instead

  8. WSDLs don’t import schemas and instead define them in-line – this might be easier to implement to start with but will cause a maintenance burden over time.

  9. Context information is not shared when implementing service to service interactions – as more reuse happens across services, it becomes essential to share context data among them. It will make authorization, logging, and integration much simpler

  10. Service business logic is in end point classes and not encapsulated well – if your service endpoints contain any logic beyond data transformation, question it to make sure that it really belongs there. Don’t implement validation rules, defaulting logic, or complex domain rules in them

...and below are strategies to tackle and reduce technical debt:

  1. Minimize redundant definitions of key domain objects (i.e. competing, conflicting definitions of the same domain object across related applications)

  2. Minimize similar solutions for slightly varying business processes and instead create common process flows

  3. Loosen tightly coupled integration/transport logic with business logic

  4. Provide consistent strategies for implementing cross cutting concerns

  5. Replace tactical implementation for a problem that has a better open-source alternative

  6. Eliminate redundant approaches for managing configuration information

  7. Harmonize multiple, incompatible interfaces and make them more domain relevant

  8. Minimize excessive coupling with a particular technology/implementation stack

  9. last but not the least – create a comprehensive suite of automated tests

Last updated