There has been a lot of silly talk lately about “technical debt” - the alleged cost of rewriting obsolete systems, and the continuing use Web1. I have mortgaged my house to fund a largely Web1-based service, so I have plenty of skin in this game which I don’t regret. Because I must say the recent criticisms leveled at Xojo Inc. are largely unjustified, and I have not been in any way contacted to write this:
Let’s look at a worst case: Suppose I built an app called “StarPos” to calculate the position of any celestial body in the night sky – in history, and into the future, from any earthly location. As such, StarPos would be the hypothetical maximum collector of technical debt possible from a dev tool perspective, because the business process never changes to make the app obsolete by itself. Let us also assume the maximum technical debt possible by building StarPos first as a desktop app, then migrating it to Web 1 and now we are at the beginning of Web2, at least according to Xojo Inc. Let us also suppose StarPos is highly graphical for a Web app, and also uses containers and grids for data in a complex way so as to very tightly bind StarPos to Web 1’s UX. So how are we going with technical debt for me as the hypothetical developer of StarPos?
Some historical perspective will help us answer: The migration from desktop to web would have been expensive but that technical debt was due to an industry-wide shake-up – mass migration from desktop APIs to HTML5. Indeed, there was nothing compelling me to make this change to StarPos from a technical standpoint, being driven by user expectations / device market growth not desktop obsolescence. In that case, Xojo decreased my ‘debt’ as there would have arguably been more commonality between desktop and web versions than with any other dev tool: For example, had I hypothetically gone with another BASIC variant, say Active Server Pages, I would have been further indebtedby the subsequent move to say VB.NET along the way.
Xojo on the other hand, updated its Web dev tool much much later to Web1 API 2.0, thus delaying the debt; and the technical debt accrued was also much much less, since Web1’s architecture didn’t change and the language was mostly unchanged. So far, so good. Now we arrive at Web 2. On the one hand, Xojo Web1 to Web2 seems much easier by comparison than a move from say VB.NET (now being depreciated) to a Java variant for example. But on the other hand, it’s unlikely the UX of StarPos can be moved from Web1 to Web2. So where are we now in relation to the alleged worst-case technical debt for me as the hypothetical developer of StarPos?
Apart from memory leaks in Web1 which I will come back to, the alleged technical debt caused by Web1 is not real at all. That’s because StarPos can be compiled for Linux or Windows which isn’t as bound to hardware updates as Apple’s offerings. This means the main contingency is that browser Web standards will be discontinued sometime in the future. How likely is that with HTML5 without plenty of notice? But let’s say HTML5 one day gets the axe. This would mainly affect the UX aspect of StarPos, not the business logic, which could be migrated to Web2 and accessed by Web1 as a web service. So there is no actual technical debt with StarPos posed by external factors yet, only a remote contingency which may or may not materialise in the future. After all, HTML 1.1 from the 1990’s still works fine today, and HTML5 is as entrenched today as 1.1 was back then. So I regard the contingent technical debt of HTML5 as negligible, as I regard the risk that the Linux APIs which Web1 runs on suddenly going away as negligible too.
There is however, technical debt of another kind, created by user expectations outside of Web1 itself, such as there was with the move from desktop to the Web. I’m speaking of the regulatory environment of some countries that has changed since Web1 was created:
As I pointed out in another post, the United States fosters innovation with a caveat emptor (let the buyer beware) approach. Software can be licenced ‘AS IS’ for example. My non-lawyer reading of Xojo’s licence, when taken together with statements made at Xojo.com inducing me to buy it for over a decade, is that it’s much more than an ‘AS IS’ licence. On my reading, we have a right to one year of future releases too for example.
However, the user expectation coming out of the German regulatory environment is very extreme. This is said to have the effect on some users, of advancing technical indebtedness by making remotely contingent liabilities, such as the abandonment of Web standards, manifest immediately by operation of law. So according to our German friends, if Web1 is not actively supported into the future, some offerings based on Web1 must soon be axed for some end users in Germany to achieve regulatory compliance. But how realistic is such an expectation of eternal life for older releases for as little as $299/year or $699/year, while still being entitled to newer developments too? Must the world stop for Germany?
Regardless, let us now unreasonably apply an apparently strict German law to StarPos as the worst of all worst cases, and compare this with another BASIC language variant. Sadly, the UX must be redone in something else, probably Java, since the law apparently requires compliance within a relatively short time. So regrettably, we must act now. Yet all is not lost, since the business logic will be relatively cheaply migrated to Web 2. Yes the affected devs will have to invest big in unit testing, but they would have to do this and probably more besides, if forced to migrate entirely to Java – plus train more staff to learn to use another tool too. For if we accept this externally imposed technical debt will inevitably apply also to VB.NET devs, Xojo devs are far better off IMHO, with the business logic ported to Web2 on Linux. I say realistically, Xojo still comes out on top even in tough segments of the German market. In fact, looking over the hypothetical lifetime of StarPos from the 1990’s, we are way way ahead in terms of technical debt having developed with RB/Xojo.
My own regulatory situation is different. My company is required by statute to guarantee merchantable quality, fitness for purpose and delivery within a reasonable time, as am I. There are no exceptions. Not only that, but whereas the the U.S. consumer laws regulate some aspects of a contract, our laws regulate a person’s entire business conduct! Fortunately, the law here is commercially equitable in what is regarded as merchantable quality, and our terms of service define what they are fit for. So although I would like Xojo Inc. to assume more of our technical debt caused by such national and state government-mandated user expectations, I’m under no illusion that they should or even could for no extra charge.
How much government-imposed technical debt should we ask Xojo Inc. to take on our behalf? This of course depends on how much we are prepared to pay. I am all for emergency fixes, such as in the unlikely event of an incompatible HTML5 standards modification, and for essential maintenance such as memory leaks. We can argue off topic if some fixes should be free of extra charge – that is not what the Xojo licence says. We can also argue off topic there should have been a transition of years from Web1 to Web2 if indeed a transition has to be made, again outside the licence. These are wonderful points I agree, but they don’t solve the problem, and are irrelevant – we test the version we paid for before we paid for it and there was no pressure to pay. Yet this arrangement is insufficient for some users, especially those in highly regulated markets who need more for the tool to be viable.
So I say there should be a budget coming from a new Web1 maintenance revenue stream for Xojo Inc. with votes for the most important fixes given through Xojo feedback. This would actually solve the problem, whereas all the winging I’ve read can only achieve nothing. In the end, it all boils down to the balance of convenience and cost, as all product features do. I believe one thing that sways the balance for Xojo Inc. to be more involved is the comparative ease of making hot-fixes for Web1, compared with the comparative difficulty for devs required to rapidly refactor customer code as is otherwise mandated by law in some markets. Or reboot servers to refresh leaky memory. There is also the financial contribution these higher-regulation markets have made to Xojo Inc.’s revenues over the years, and the need to meet their aspirations for this to continue.
Of course a maintenance scheme for Web1 would also mean people like me all over the world wouldn’t have to explain all this to potential investors. However, an investor who can’t understand it probably shouldn’t invest in software at all, since un-knowledgeable investors often hurt their investments when the going gets tough. I trust we are not so silly as to do that.
but it seems there’s no way.
is also a legitimate complaint. Also your analogy is technically more accurate than mine in the sense that Web1 and Web2 are frameworks not languages. But therein lies the problem with what you are saying:
Again in the case of VB6, it was discontinued BUT NOT ABANDONED. The tool itself had 6 Service packs in 10 years and and multiple security fixes after that. Also the runtimes are kept updated to work with the latest OS, to this day, 23 years later, vb6 apps are still running in the latest windows 10 and windows server.