Following on from my last blog on "going beyond the cool demo", here are some thoughts around creating technical debt.
It is incredibly encouraging how many companies are now embarking on an XR (eXtended Reality) journey. Many have managed to find some internal investment and commitment to do a Proof of Concept (PoC) project to start to understand how these emerging technologies can improve their business.
Whilst some engage with outside help, others decide to embark on the journey themselves. Both are great, in that, the only way to understand and prove that the technology has significant time saving and cost benefits, is to actually do it!
But, by going it alone you may well be introducing technical debt into your organisation. Technical debt describes what happens when software development teams take actions to expedite the delivery of a piece of functionality or a project which will later need to be re-worked. In other words, it’s the result of prioritizing a quick delivery over a perfect solution.
Technical debt is a phrase originally coined by software developer, Ward Cunningham (@WardCunningham). He first used the metaphor to explain to non-technical stakeholders at WyCash why resources needed to be budgeted for refactoring.
Ward said “With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money, you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.”
Ward didn’t realize at the time, but he had just created a new buzzword in the software community.
As Ward suggested, if technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes later on. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward. But, you can encounter problems down the road.
For example, by creating a PoC in-house, you rely on the skills of your staff members. If the business restructures, you may find that these resources are no longer available to you; so, who will continue their work, and move it on to the next phase, if they are no longer there?
There are many reasons why you could find yourself in the situation of creating this technical debt. This technology is new, so it is quite possible that there was insufficient up-front definition; often requirements are still being defined during design or development. Agile software development is all about iterations and rapid delivery but often this means that the solution has to be reworked later.
Business pressures, where there is a concern that not doing something will lead to a competitive disadvantage, leads to something being released sooner, before all of the necessary changes are complete. This builds up technical debt comprising those uncompleted changes.
Or, there could be a lack of process or understanding of the desired outcome; where businesses are blind to the concept of technical debt and make decisions without considering the implications.
By reading this, you may now be put off from starting your XR journey; but don’t be. Just make sure that you understand the implications of your decisions before you start.
Some issues that we have encountered with our clients include, not thinking about what will happen when your CAD vendor no longer supports the version of software that you are using. Your processes are absolutely dependent on your 3D CAD and your ability to integrate it in VR/MR but your working solution is now end-of-life.
A solution like our Visualization Pipeline would ensure that this does not happen. At Theorem we work with all of the major CAD vendors to ensure that our software works with the latest versions. This means that getting your 3D content into your visualization software remains consistent. You can upgrade, or even change your CAD supplier, and your path to visualization remains intact.
Another issue that we have encountered is around the hardware. In the last couple of months there must have been 5, 6, or maybe more product announcements from various companies showing the latest head mounted display technologies. How do you know which is the right one to choose? It is really important to have a device agnostic approach. Often companies look like they have the best device which is going to revolutionize the market- look at Meta 2, or Star VR. Both of these no longer exist. By taking an agnostic approach, rather than pinning all your hopes on one device can save you from the headache of being stuck with obsolete and unsupported hardware, that may also still be “brand new”…
If you liked this blog, then this may also be of interest: Exploring the Cognitive Gap and the potential of XR technologies.
