How and why to avoid custom code and technical debt
First published on the miggle blog 20/3/16 — written by Adam Browne
Why it’s worth doing code right — and ideally, without custom code
Technical debt is a metaphor that equates software development to financial debt. If the debt is not repaid, “interest payments” mount and make future progress increasingly difficult.
The Value/Visibility quadrant expresses it well — technical debt is invisible negative value.
It’s not necessarily bad — technical debt can help you get to a desired result, just like taking on financial debt. But you need to plan for it to be paid back. If this doesn’t happen, your site will become more complex, and more difficult to maintain and improve in the future.
Sources of technical debt
Bad coding
Developers are human, and sometimes they don’t make the right decisions on how to implement something — or they don’t document the code properly, which makes it difficult for someone else to come along later and figure out how it works.
miggle follows Drupal’s coding standards and best practices, so we can check if there’s an approved method for various functions, and other Drupal developers should be able to follow work we’ve done.
Bad specifications
Site builders and developers can only work to the information they’re given. If a client doesn’t provide the right information — perhaps because they haven’t analyzed their own processes or business needs, or because they don’t know enough about the technical implications — development can go down a path which will need to be redirected later.
miggle’s validation processes help to minimize this — we don’t just take specifications at face value, but question them to make sure we avoid going down dead ends.
Shortcuts
Under pressure of deadlines, sometimes a decision needs to be made to use a quicker process rather than the ideal one. This doesn’t have to be a bad decision, so long as everyone understands the limitations of the short-term solutions and the possibility that some work may need to be redone.
Custom solutions
Finally, it may be that there are no existing solutions which match the requirements. In this case it’s tempting to write some custom code to give the client exactly what they want. This may be the best solution — but the client will need to understand the implications, including future maintenance and modification.
miggle uses existing open-source solutions wherever possible, and where custom code has been necessary we contribute this back to the Drupal community wherever possible.
Credits and sources
- http://www.aeqblog.ca/technical-debt-the-good-the-bad-and-the-ugly-2/
- https://www.atlassian.com/agile/technical-debt/
- http://martinfowler.com/bliki/TechnicalDebt.html
- https://www.techopedia.com/definition/27913/technical-debt
- https://en.wikipedia.org/wiki/Technical_debt
- https://en.wikipedia.org/wiki/Ward_Cunningham
Digital decisions are never a walk in the park, so let me help you find the right way through the technical landscape.