The Decline of Usability

As I see it, there are great swathes of poor and substandard software on the market that shouldn't be there except for the fact that there's either no suitable alternative, or if reasonably good alternatives do exist then they're just too expensive for ordinary people to use (i.e.: such software isn't in widespread use). I base this (a) on my own long experience where I encounter serious bugs and limitations in both commercial and open source software as day-to-day occurrences; and (b), data I've gathered from a multitude of other reports of users' similar experiences.

(Note: I cannot possibly cover this huge subject or do it reasonable justice here as just too involved, even if I gave a précised list of headings/topics it wouldn't be very helpful so I can only make a few general points.)

1. The software profession has been in a chronic crisis or decades. This isn't just my opinion, many believe it fact. For starters, I'd suggest you read the report in September 1994 edition of Scientific American titled Software's Chronic Crisis, Wayt Gibbs, pp 86-95: https://www.researchgate.net/publication/247573088_Software'... [PDF]. (If this link doesn't work, then a search will find many more references to it.)

1.1 In short, this article is now nearly 26 years old but it's still essentially the quintessential summary on problems with software and the software industry generally (right, not much has changed in the high-level sense since then, that's the relevant point here). In essence, it says or strongly implies:

(a) 'Software engineering' really isn't yet a true engineering profession such as chemical, civil and electrical engineering are and the reasons for this are:

(b) As a profession,'Software engineering' is immature, it 'equates' [my word] to where the chemical profession was ca 1800 [article's ref.], (unlike most other engineering professions, at best it's only existed about a third to a quarter the time of the others).

(c) As such, it hasn't yet developed mandatory standards and consistent procedures and methodologies for doing things—even basic things, which by now, ought to be procedural. For instance, all qualified civil engineers would be able to calculate/analyze static loadings on trusses and specify the correct grades of steel, etc. for any given job or circumstance. Essentially, such calculations would be consistent across the profession due to a multitude of country and international legally-mandated standards which, to ensure safety, are enforceable at law. Such standards have been in place for many decades. Whilst the 'Software Profession' does have standards, essentially none are legally enforceable. Can you imagine Microsoft being fined for, say, not following the W3C HTML standard in Windows/Internet Explorer to the letter? Right, in this regard, software standards and regulations are an almighty joke!

(d) Unlike other engineering professions, software engineers aren't required by law to be qualified to a certain educational standard [that their employers may require it is irrelevant], nor are they actually licensed to practice as such. When 'Software engineering' eventually becomes a true profession then these requirements will almost certainly be prerequisites for all practitioners.

(e) With no agreed work procedures or mandated work methodologies across the profession 'software engineers' are essentially 'undisciplined'. As such, the SciAm article posits that software programmers work more akin the way of artists than that of professional engineers.

(As a person who has worked in both IT/software and in an engineering profession for years, I have to agree with Wayt Gibbs' assessment. There are practices that are generally acceptable in software engineering, which if I attempted to equate them to an equivalent circumstance with my engineering hat on, then I'd likely end up in court (even if no one was killed or injured by what I'd done. Here, the rules, the structure—the whole ethos is different, and both ethics and law play much stronger roles than they do in software-land).

2. You may well argue that even though Computing Science is not as old as the other engineering professions, it, nevertheless, is based on solid mathematics and engineering foundations. I fully agree with this statement. However, without enforceable standards and licensed/qualified software practitioners, the industry is nothing other than just 'Wild West' engineering—as we've already seen, in software just about anything goes—thus the quality or standard of software at best is only that of the programmer or his/her employer.

3. As a result, the quality of product across the industry is hugely variable. For example take bloatware: compare the biggest bloatware O/S program ever written, MS Windows, with that of tiny, fast and highly efficient Kolibrios OS, built on Assembler https://kolibrios.org/en/ (here I'm referring to methodology rather than functions — we can debate this later).

4. The commercial software industry hides behind the fact that its software is compiled, thus its source code is hidden from public view and external scrutiny. Its argument is that this is necessary to protect its so-called intellectual property. Others would argue that in the past loss of IP was never really the main issue, as manufacturing processes were essentially open—even up until very recent times. Sure, it could be argued that some manufacturing had secrets [such as Coca Cola's formula, which really is only secret from the public, not its competitors], but rather industrial secrets are normally concerned with (and applied to) the actual manufacturing process rather than the content or parts of the finished product. That's why up until the very recent past most manufacturers were only too happy to provide users with detailed handbooks and schematics; for protection from copies they always relied on copyright and patent law as protection (and for many, many decades this protection process worked just fine). It's a farce to say that commercial 'open source' isn't viable if it's open. Tragically, this is one of the biggest con job the software industry has gotten away with—it's conned millions into believing this nonsense. More the true reason is that the industry couldn't believe it's luck when it found that compilers hid code well — a fact that it then used opportunistically to its advantage. (Likely the only real damage that would be done by opening its source is the embarrassment it'd suffer when others saw the terrible standard of its lousy, buggy code.)

4.1 'Software engineering' won't become a true profession until this 'hiding under compilation' nexus is broken. There are too many things that can go wrong with closed software—at one end we've unintentional bugs that cannot be checked by third parties, at the other we've security, spyware and privacy issues that can be and which are regularly abused; and there's also the easy possibility of major corruption—for instance, the Volkswagen scandal.

5. Back to your comment about 'good design not being free'. I'm very cognizant of the major resource problems that free and open source software developers face. That said, we shouldn't pretend that they don't exist, nor should we deliberately hide them. I accept that what we do about it is an extremely difficult problem to solve. My own suggestion to up the standard of open software is a sort of halfway house where cooperatives of programmers would be paid reasonably acceptable remuneration for their contribution to these major open projects. In turn, there would be a small nominal free (say $5 to $20) levied on large scale open software programs such as GIMP, LibreOffice, ReactOS etc. to ensure that development could go ahead at a reasonable pace (the projects otherwise would be revenue neutral—there would be no profits given to third parties).

Let me finish by saying that whilst commercial software has the edge over much free/open software (for example MS Office still has the Edge over LibreOffice), that edge is small and I believe the latter can catch up if the 'funding/resource' paradigm is changed just marginally. Much commercial software such as MS Office is really in a horrible bloated spaghetti-code-like mess and with better funding it wouldn't take a huge effort for dedicated open software programmers to beat their sloppy secretive counterparts at their own game. After all, for many commercial programmers, programming is just a job, on the other hand open software aficionados are usually doing it for the love of it—and that's a true strategic advantage.

I firmly believe that for open software to really take off it has to be as good as and preferably better than its commercial equivalent. Moreover, I believe this is both possible and necessary. We never want a repeat of what happened in Munich where Microsoft was able to oust Linux and LibreOffice. With Munich, had it been possible to actually demonstrate that the open code was substantially and technically superior to that of Microsoft's products, then in any ensuing legal battle Microsoft would have had to lose. Unfortunately that was not possible, so the political decision held.

One thing is for certain, we urgently need to raise the standard of software generally and it seems highly unlikely that we can do so with the way the industry is currently structured.

Also, problem solving and creative thinking are never outdated skills. ;-)

Users, show precious little allegiance to any app when it balks them or they cannot find an easy way to do what they want to (run a help desk for a week and you'll get that message loud and clear).