By Lance Eliot, the AI Trends Insider
Getting in over your head. That’s what often happens when people take on debt.
Shakespeare famously warned us about the dangers of going into debt, stating that “neither a borrower nor a lender is; for loan doth oft lose both itself and friend.” For some people that become swamped by debt, they find themselves sinking into an all-encompassing abyss. The debt impacts them, their loved ones, their friends and acquaintances, and otherwise bodes for indubitably rotten tidings.
Sometimes, a person is oblivious to their mounting debt.
I know that seems nearly impossible to imagine. What can happen is that the person starts making zillions of charges on their credit cards, and they meanwhile delude themselves into not realizing there will ultimately be unfavorable consequences. The piper, though, will eventually need to be paid.
Credit card agencies often make life especially easy for those that wantonly are apt to spend. Charge this, charge that, and it all seems like free money. You have a seemingly endless credit limit, so why not keep spending. Little or no thought goes toward how this is going to get paid for.
Some people realize what they are doing, but are hooked on spending recklessly. It can be like a gambling addiction. They might overtly know that what they are doing is racking up a debt that they can never afford to repay. But turns out that the urge to go into debt is seemingly greater than the stopping forces to prevent it.
More variations arise.
Some people know they are getting themselves into a lot of debt and do so straightforwardly. They are anticipating that the money being borrowed will provide a sizable payoff. Taking on debt could be highly profitable, and there are lots of instances where this has been a proven strategy.
They say that at times the debt rainbow can lead to a pot of gold at the end. That’s at least the grand hope, unless of course the payoff never happens. Oopsie.
Why all this talk about debt?
Technical Debt In Software
Because there is another kind of debt that few know about, a type of debt that arises in the software development realm and has been coined as technical debt.
To be clear, technical debt can arise in any engineering or technological endeavor. I’m going to focus on the nature of technical debt in the context of software systems. Please keep in mind that the same notions can be applied to lots of other tech-oriented contexts.
Here’s how technical debt in software arises.
A software engineer is working night and day on a programming project. It is a hard-fought battle. A timeline has been established for getting the code done and put into production by the end of the month. This is a ridiculous deadline, and the programmer is at his or her wit’s end as to how the coding can be finished by that rapidly approaching date.
Most seasoned programmers are used to these kinds of scenarios, which seem to happen frequently. Rather than receiving a deadline that is based on what can be done, there is a tendency for others to assign deadlines simply based on other whims that have nothing to do with the actual programming required. Get things done by this date is the mantra, regardless that the date was plucked from thin air or based on a dreamy whimsy.
Anyway, a programmer is apt to decide that to meet the deadline will require doing a bit of flimflam on the coding. Good programming practices dictate that you ought to build in error handling so that your code will be resilient and able to handle gotchas that occur once the program is put into use.
Nice idea, but that’s going to get placed aside, for now, the hectic programmer decides. The programmer doubts there are many errors in the code, and thus the error handling won’t especially ever be needed. So, skip it, for now.
Technical debt has entered this scenario.
In essence, the program has taken on a form of debt. The debt is a future cost that for the moment seems worthwhile. Put off for today that which can be dealt with at some later unspecified date.
Nobody will presumably notice the debt for now. It is hidden from view. The programmer knows about it. Whether the managers overseeing the project know about it is another question. Sometimes they do, and they encourage the debt, aiming to attain the touted and prized deadline on time. Sometimes the debt is only known to those that are creating it. Others that are presently unaware will, on a later occasion, find out to their dismay that the code is laden with such debt.
Jettisoning the Error Handling Might Not Be Enough
Returning to the scenario, the programmer determines that omitting the error handling is not going to be enough of a jettison to reach the deadline. Something else has to be tossed over the side of this boat. After giving the matter some thought, the programmer stops documenting the code and goes into a heads-down mode of churning out lines upon lines of code.
Yes, that’s another kind of technical debt that has been added to this mounting stack.
The programmer figures that since he or she personally produced the code and knows it by heart, there is no need to document it. No need to write down what the code does. No need to proffer inline explanations. The programmer believes that the code is so transparent and so obvious that anyone coming along to later update or modify the code will immediately understand it. Plus, documentation is not much fun and won’t aid in meeting the deadline of having an app that works.
For those of you that aren’t programmers, you might not realize this is a rather common refrain by some alleged purists of coding. They don’t want to mar their code with commentary, nor waste their precious mind on doing something considered mundane. The thing is, these same programmers will often curse themselves later when called back to revise their prior code, since they no longer remember what was in their minds when they generated it.
In addition, any programmer that has ever had to take over someone else’s code will undoubtedly tell you that it can be a nightmare to divine what the other programmer was trying to do. The code itself is insufficient to showcase what the purpose is. Without some documentation, albeit even meager or scant documentation, the code can be an enigma that either takes an excessive amount of time and effort to figure out, or you end chucking the code and starting anew.
We’ve now got two variants of technical debt in this situation: lack of error handling and the paucity of documentation.
You might be tempted to assume that the impact is marginal; it seems like nothing of great consequence is being owed.
Sorry, that’s akin to playing the odds at the roulette wheel.
Let’s assume that those incurred technical debts are able to allow the programmer to attain the end of the month deadline. Hurray! The deadline was achieved and all are happy with the now underway app.
Lurking in the shadows, though, is the ominous technical debt.
Imagine that after the app is in use for a week or two, all of a sudden the code reaches an unexpected error. Yikes! Without the error handling capabilities, the app has no provision about what to do. The app shuts down each time that the error occurs.
People using the app are furious.
What the heck is going on with this crazy app. One minute it seems to be working just fine, and the next moment it inexplicably closes down. Carping about this bizarre behavior spreads. Those that at first hailed the app as a tremendous breakthrough are now warning that you cannot count on it. At the worst of times, it can get flaky and die on you.
You see, the debt is now being paid, rather involuntarily one might say.
The cost to pay this technical debt could be enormous. Perhaps the app is no longer used by anyone. On top of that, whoever developed the app could face reputational ruin. You might anticipate lawsuits too, assuming that those using the app might believe that they suffered some form of losses due to the flakiness of the app.
In short, the cost to cover this technical debt might be many times more than the perceived debt value at the time it was initially incurred.
We can go further. A different programmer is quickly brought in to resurrect the app. Upon looking at the code, the programmer is dismayed and taken aback that there is absolutely no documentation. The code is inscrutable. It is going to take weeks or maybe months to decipher.
The technical debt of not having documentation now rears its ugly head. This was not apparent by those that were earlier running the app as they had only encountered the other technical debt (i.e., the error handling technical debt).
As a rule of thumb, some technical debt will be readily witnessed or experienced, while other kinds of technical debt can remain hidden and elusive.
There is also the concept of garnering interest on technical debt, similar to incurring interest on financial debt. Suppose the programmer that is brought in to modify the code can successfully do so, and meanwhile doesn’t document what they are doing. You could say that the technical debt associated with the lack of documentation is growing in interest or being further piled onto.
One other aspect to be aware of is that technical debt can happen at any stage of software development. I’ve focused for the moment on code debt, which is ostensibly the most popularly discussed instance of software technical debt.
You can also have software design debt. That’s when you scrimp or incur technical debt during the design stage or phase of developing a system. This happens quite frequently, whereby there is angst to move right away into coding and so the design efforts are shortchanged. The shortchanged design elements are a form of technical design debt that will someday need to be repaid.
Another stage or phase of software technical debt consists of testing debt. Developers do this all the time. When deadlines are nearing, the seemingly easiest thing to do is shorten or narrow the amount of testing that is going to be done. There is that infamous Silicon Valley mindset that it is best to move fast and break things. This includes a willingness to forgo extensive testing and just let the end-users become the testers.
That can be sensible, or it can be a horrendous choice. If an application is going to be used in simple ways and not be a life-or-death matter, you can potentially get away with piles of technical debt. Those that use the app might shrug off the problems of the app. They might be excited to be able to use the app, perhaps being in a beta group that gets access sooner than others.
The problem is that any life-or-death software that has technical debt is like a ticking time bomb. Depending upon the nature of the software technical debt involved, the consequences of that underlying debt might cause notable damages or harm.
One area that is already starting to encounter the throes of technical debt includes AI-based systems. I refer to this as AI technical debt.
Though you might be assuming that AI systems are surely developed with the utmost of heightened stringent controls and capabilities, you’d be sadly mistaken. Indeed, as I’ve often pointed out, the pell-mell rush toward crafting AI systems has regrettably led to a goldrush that is ridden with software that is unreliable, poorly tested, and waiting to fail.
Let’s then combine the overall software technical debt aspects and the AI goldrush, tying this amalgamation to matters entailing real-time life-or-death types of systems.
Where can such facets converge?
Answer: AI-based self-driving cars.
That might seem surprising. Well, get used to it. There is AI technical debt right now being incurred in the development of AI self-driving cars.
The piper will someday need to be repaid.
This is an alarming realization when you somberly consider that the future of cars consists of AI-based true self-driving cars. There isn’t a human driver involved in a true self-driving car. Keep in mind that true self-driving cars are driven via an AI driving system. There isn’t a need for a human driver at the wheel, and nor is there a provision for a human to drive the vehicle.
Here’s an intriguing question that is worth pondering: How might AI technical debt potentially undermine the advent of AI-based true self-driving cars?
I’d like to first further clarify what is meant when I refer to true self-driving cars.
For my framework about AI autonomous cars, see the link here: https://aitrends.com/ai-insider/framework-ai-self-driving-driverless-cars-big-picture/
Why this is a moonshot effort, see my explanation here: https://aitrends.com/ai-insider/self-driving-car-mother-ai-projects-moonshot/
For more about the levels as a type of Richter scale, see my discussion here: https://aitrends.com/ai-insider/richter-scale-levels-self-driving-cars/
For the argument about bifurcating the levels, see my explanation here: https://aitrends.com/ai-insider/reframing-ai-levels-for-self-driving-cars-bifurcation-of-autonomy/
Understanding The Levels Of Self-Driving Cars
As a clarification, true self-driving cars are ones where the AI drives the car entirely on its own and there isn’t any human assistance during the driving task.
These driverless vehicles are considered Level 4 and Level 5, while a car that requires a human driver to co-share the driving effort is usually considered at Level 2 or Level 3. The cars that co-share the driving task are described as being semi-autonomous, and typically contain a variety of automated add-on’s that are referred to as ADAS (Advanced Driver-Assistance Systems).
There is not yet a true self-driving car at Level 5, which we don’t yet even know if this will be possible to achieve, and nor how long it will take to get there.
Meanwhile, the Level 4 efforts are gradually trying to get some traction by undergoing very narrow and selective public roadway trials, though there is controversy over whether this testing should be allowed per se (we are all life-or-death guinea pigs in an experiment taking place on our highways and byways, some contend).
Since semi-autonomous cars require a human driver, the adoption of those types of cars won’t be markedly different from driving conventional vehicles, so there’s not much new per se to cover about them on this topic (though, as you’ll see in a moment, the points next made are generally applicable).
For semi-autonomous cars, it is important that the public needs to be forewarned about a disturbing aspect that’s been arising lately, namely that despite those human drivers that keep posting videos of themselves falling asleep at the wheel of a Level 2 or Level 3 car, we all need to avoid being misled into believing that the driver can take away their attention from the driving task while driving a semi-autonomous car.
You are the responsible party for the driving actions of the vehicle, regardless of how much automation might be tossed into a Level 2 or Level 3.
For why remote piloting or operating of self-driving cars is generally eschewed, see my explanation here: https://aitrends.com/ai-insider/remote-piloting-is-a-self-driving-car-crutch/
To be wary of fake news about self-driving cars, see my tips here: https://aitrends.com/ai-insider/ai-fake-news-about-self-driving-cars/
The ethical implications of AI driving systems are significant, see my indication here: http://aitrends.com/selfdrivingcars/ethically-ambiguous-self-driving-cars/
Be aware of the pitfalls of normalization of deviance when it comes to self-driving cars, here’s my call to arms: https://aitrends.com/ai-insider/normalization-of-deviance-endangers-ai-self-driving-cars/
Self-Driving Cars And AI Technical Debt
For Level 4 and Level 5 true self-driving vehicles, there won’t be a human driver involved in the driving task. All occupants will be passengers; the AI is doing the driving.
One aspect to immediately discuss entails the fact that the AI involved in today’s AI driving systems is not sentient. In other words, the AI is altogether a collective of computer-based programming and algorithms, and most assuredly not able to reason in the same manner that humans can.
Why is this added emphasis about the AI not being sentient?
Because I want to underscore that when discussing the role of the AI driving system, I am not ascribing human qualities to the AI. Please be aware that there is an ongoing and dangerous tendency these days to anthropomorphize AI. In essence, people are assigning human-like sentience to today’s AI, despite the undeniable and inarguable fact that no such AI exists as yet.
With that clarification, you can envision that the AI driving system won’t natively somehow “know” about the facets of driving. Driving and all that it entails will need to be programmed as part of the hardware and software of the self-driving car.
Let’s dive into the myriad of aspects that come to play on this topic.
There is AI technical debt aplenty amidst the AI driving systems and related code of today’s budding self-driving cars.
First, some estimates are that there could be around 100 million lines of code or more that exist to empower and enable the capabilities of a self-driving car. This includes proprietary code that a particular automaker or self-driving tech firm has devised for their self-driving cars. Also included are the reams and reams of third-party code, such as the use of open-source code that is intermixed into the AI driving systems and other components.
Scarily, many firms are unaware of how much AI technical debt they are sitting atop.
This is somewhat akin to those people that take on financial debt and aren’t aware that they are doing so. It just kind of happens. Debt is incurred and not noted or tracked. The same can be said for some of the AI development groups and their amazing efforts to craft AI driving systems. They are incurring AI technical debt here and there, right and left, above and below, yet there isn’t an explicit effort toward noting that it is piling up.
Where might this AI technical debt reside?
One of the most significant arenas consists of the AI underlying the sensory suite and all of its machinations.
The sensors for self-driving cars are crucial. By and large, sensors are being used that encompass real-time video cameras, radar, LIDAR, ultrasonic detection, thermal imaging, and so on (the choice of which kinds of sensors to use is highly variable and differs from firm to firm).
The sensors are essentially the eyes and ears of the AI driving system. During a driving journey, data is streaming into the sensors and being computationally analyzed. A significant means of doing the needed computational pattern matching consists of utilizing Machine Learning (ML) and Deep Learning (DL). Besides analyzing the data directly, there is also the need to perform Multi-Sensor Data Fusion (MSDF), bringing together the data and seeking to align and triangulate the interpretations of the driving scene.
Hidden within all of the complex code for these sensory uses is all manner of AI technical debt.
Some of the debt has been incurred by a rush to pull together the AI driving system and try to get a self-driving car up and going for tryouts. Some of the debt exists as a result of putting a myriad of AI developers to the task of developing the code, stretching the skills of novice AI developers, or pushing to the brink the skills of savvy AI developers. In addition, this is at times being undertaken without rigorous tracking and software coding practices being set up and observed.
I’ve described previously that the AI development efforts for self-driving cars can be given an overly wide berth and allowed to do their “magic” without the typical rigors expected of similar real-time life-or-death systems of this nature.
There are relatively few self-driving car makers that are directly watching out for AI technical debt.
What they all need to do is take a comprehensive inventory of their enormous efforts and figure out where that AI technical debt is potentially lurking. This can be painstaking and painful to do. Finger-pointing and all manner of unsightly blame-game exhortations can arise.
The easier path is to just wait and see what happens.
Note too that the AI technical debt can arise throughout each of the stages or phases of a self-driving car and its life cycle. It could be that there are design debt aspects that have yet to be uncovered, perhaps only gaining visibility once the self-driving car is underway on roadway trials. That’s a bad time to be running into the skulking technical debt.
For more details about ODDs, see my indication at this link here: https://www.aitrends.com/ai-insider/amalgamating-of-operational-design-domains-odds-for-ai-self-driving-cars/
On the topic of off-road self-driving cars, here’s my details elicitation: https://www.aitrends.com/ai-insider/off-roading-as-a-challenging-use-case-for-ai-autonomous-cars/
I’ve urged that there must be a Chief Safety Officer at self-driving car makers, here’s the scoop: https://www.aitrends.com/ai-insider/chief-safety-officers-needed-in-ai-the-case-of-ai-self-driving-cars/
Expect that lawsuits are going to gradually become a significant part of the self-driving car industry, see my explanatory details here: http://aitrends.com/selfdrivingcars/self-driving-car-lawsuits-bonanza-ahead/
Conclusion
There are numerous additional twists and turns. I’ll mention just a few more.
Though the AI technical debt can be demonstratively bad, it can also be somewhat of a “necessity” in some cases, though this comes with a big caveat. If an AI team is at least aware of where the technical debt is being incurred, they can consider the tradeoffs of allowing it to exist. They can try to minimize the dangers of the debt. They can seek to reduce the amount of debt-related technical interest that will be accrued.
What should not happen is the outright hiding of any mounting AI technical debt. Trying to keep upper management in the dark about the technical debt is going to be unseemly in the end, for everyone involved. Pressures to meet deadlines or to keep costs tapped down are certainly primal urges to go ahead and allow technical debt to soak into the AI driving system.
Lamentably, those that are outspoken can find themselves internally blacklisted for decrying the generation of software technical debt (see my coverage of insider naysayers and also whistleblowers).
All told, if an existing self-driving car development effort isn’t already on top of the AI technical debt phenomena, it is time to do something about it.
Better late than never.
And remember the immortal words of Benjamin Franklin in his 1758 treatise entitled The Way To Wealth: “The second vice is lying, and the first is running in debt.”
Good old Ben knew what he was talking about back then, and which still applies in today’s state-of-the-art AI-infused self-driving cars emergent world. This is undeniably sage wisdom worthy of posting on the cubicle walls of contemporary AI developers and their managers.
Copyright 2021 Dr. Lance Eliot
http://ai-selfdriving-cars.libsyn.com/website
Read MoreAI Trends
