Well, the holidays have come and gone and we’re now left with the bills – a sober reminder of just how good the holidays actually were….right down to the penny. While very few of us are able to navigate through life debt-free, I want to take this opportunity to discuss a type of debt no one in our field is immune to, and that is Technical Debt.

Last year I attended a talk given by DevOps guru, Gene Kim. It was there I first learned of the term, Technical Debt. As it turned out it’s not a new term at all. The technical debt metaphor was first coined some 25 years ago by Ward Cunningham who explained it as:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

As an aside, he is also credited with the equally brilliant:

The best way to get the right answer on the Internet is not to ask a question,
but to post the wrong answer!

Getting back to Technical Debt… Cunningham’s quote makes perfect sense, doesn’t it? In the course of developing software, corners do get cut. Pressures are brought to bear on the process. Timelines are squeezed. It’s been that way since day one, but now we have a name for it – Technical Debt. Now we can better understand just how “expensive” it is to take those actions. Now we understand left unattended, the technical debt will continue to mount affecting everything including the velocity at which future enhancements can be deployed.

The fact that Cunningham was able to draw such parallels to financial debt puts it in terms we can all understand and relate to. As with financial debt, simply making minimum payments only prolongs the inevitable. At some point, the focus must be on attacking the principle and not simply making interest payments.

There is one exception and that is if a software system is to be retired, all technical debt it is carrying is also retired…automatically. In that case, if the resources required to remedy exceed the remaining life, it makes more sense to simply ride out the string.

Common Causes of Technical Debt

My research on the topic led me to the following list of technical debt common causes…

• Business pressures – where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes.
• Lack of process or understanding – where businesses are blind to the concept of technical debt, and make decisions without considering the implications.
• Lack of building loosely coupled components – where functions are not modular, the software is not flexible enough to adapt to changes in business needs.
• Lack of a test suite – which encourages quick and risky band-aids to fix bugs.
• Lack of documentation – where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid.
• Lack of collaboration – where knowledge isn’t shared around the organization and business efficiency suffers, or junior developers are not properly mentored.
• Parallel development at the same time on two or more branches can cause the buildup of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up.
• Delayed refactoring – As the requirements for a project evolve, it may become clear that parts of the code have become unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.
• Lack of alignment to standards – where industry standard features, frameworks, technologies are ignored. Eventually, integration with standards will come, doing sooner will cost less (similar to ‘delayed refactoring’).
• Lack of knowledge – when the developer simply doesn’t know how to write elegant code.
• Lack of ownership – when outsourced software efforts result in in-house engineering being required to refactor or rewrite outsourced code.
• Poor technological leadership – where poorly thought out commands handed down the chain of command increases the technical debt rather than reduce it.
• Last minute specification changes – these have potential to percolate throughout a project but no time or budget to see them through with documentation and checks.

Quite a list. I prefer to distill them down to the following four:

• Bad Architectural Design

• Insufficient Documentation

• Lack of Test Coverage

• Poor or Inconsistent Code Quality

How can Oracle APEX minimize that initial debt load?

Of the four causes listed above, Oracle APEX can address bad architectural design and poor code quality. APEX specifically targets poor or inconsistent code quality with the following…

PL/SQL Packages

One of the key ways to mitigate technical debt is to minimize code duplication. By moving PL/SQL code from your APEX application to packages in the database, business logic can be easily reused.

Subscriptions

Maintaining, for instance, a corporate look and feel is easily attained using subscriptions. Subscriptions allow for the sharing of templates, LOV’s, authorization schemes, etc. across multiple applications.

APEX Advisor

The APEX Advisor enables you to check the integrity and quality of your application. Advisor functions like a compiler or LINT and flags suspicious behavior or errors. Running Advisor checks the integrity of your application based on the underlying metadata. Each subsequent release of Application Express further tightens the rules engine, such as invalid developer code that was ignored previously may now produce an error. The Advisor will identify these issues as errors, along with numerous other warnings, to improve the quality of your applications.

User Interface (UI) Defaults

User interface defaults enable you to assign default user interface properties to a table, column, or view within a specified schema. When you create a form or report using a wizard, the wizard uses this information to create default values for region and item properties. Utilizing user interface defaults can provide consistency across multiple pages in an application

Conclusion

It has been said that every software project carries some technical debt. I do believe that’s true, however using APEX can minimize that initial debt load. Understand the debt will only increase over time so it is very important that the focus be on refactoring to keep things somewhat in check.
If you need technical debt counseling, please contact the professionals at Insum Solutions for a free consultation.

Share this: