by Dave Iberson-Hurst, CTO
A few months ago, I was reading a document whose title and contents have long since left my memory, when I came across an unfamiliar term. The term was “technical debt”. So, as ever, out came google and the resulting Wikipedia search result:
Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
Having read the description / definition on Wikipedia, I nodded to myself and thought,“yeah, been there”. It was also comforting that, while not recognizing the term, I knew what the notion was. I also rather liked the idea, as it sums up a concept that most software developers will be familiar with.
The CDISC Standards Debt
But then my mind wandered. I started thinking about CDISC standards. While not software, I begin to explore in my head the idea that ‘technical debt’ is one of the biggest issues in the CDISC world of clinical research data standards. During this pondering and starring uselessly into space, I was reminded of a blog post from 2011 and a book I had read (The 10 Commandments of Effective Standards Development by Karen Bartleson)about standards development.
Commandment 10 was, “Know That Standards Have Technical and Business Aspects” and I wrote,
There are many in standards development who believe that just because a standard is produced the game is over. In reality it has only just begun, like any other product, the standard needs to be sold, it must be fit for purpose and have business benefit. This is rarely, if ever, mentioned during standards gatherings.
CDISC standards are technical standards and the phrase, “just because a standard is produced the game is over”, is one that I would argue we suffer from. We have tinkered, added bits here and there, we have increased the coverage of our products, but we have not updated the core fundamentals and improved our world.
Technical debt exhibits itself within our CDISC standards in many ways: that latest terminology change that might have been avoided, the overloading of variables within SDTM. A good example is the variable –CAT, see this paper presented by Johannes Ulander and Niels Both at PhUSE, for an analysis of just CAT and its use within MH.
Now, of course, the issue with the ‘CDISC Product’ is that we have a large installed user base. Any significant change may have considerable impact on users. But if we don’t improve, we slowly start falling behind until the debt becomes so large that we need to start again.
Avoiding the Square Wheel
So, what do we do? Well there are some steps being taken. The CDISC Blue Ribbon Commission, of which I am a member, has been in operation for some time, while CDISC has started to talk more openly about CDISC 2.0 and announced initiatives at the latest conference in the US. I think we need to consider ‘technical debt’ as part of our development processes to ensure that we don’t always take the easy route when updating the CDISC standards and we think of the future a little more. What are your thoughts? Where is your technical debt?