[Interest] Interest Digest, Vol 73, Issue 14

[Roland Hughes]

On 10/08/2017 10:41 AM, interest-request at qt-project.org wrote:
>    - schedule a triage week every couple of months to go through the current
> backlog and reassess/re-prioritize? (again, don't know if this is done -
> doesn't seem like it from the outside)
>
> This should maybe also include the bugreports whose assignee went missing
> years ago and are just stalled (or worse, "closed due to inactivity").
Yes, once the 12 year old boy who volunteered to fix it actually 
discovers girls, well, their interest in programming vaporizes...<Grin>
> I must say in choir with the others posters here that I wanted to
> contribute a bit but I'm honestly giving up after some weeks of doing
> changes -> calling maintainers -> maintainers suggest another set of
> changes, etc., mostly because this means that by the time my patch actually
> ends up in a released version of qt it's almost a year (plus realistically
> a few more months waiting for the usual patch releases to sort out problems
> with macOS 10.18 "Random Waterfall")... I may not even be working on qt
> software (or software at all) so far in time so the effort / reward ratio
> ends up being less interesting than contributing to projects where the
> whole "propose patch -> CI & sanity check pass -> patch applied" process is
> a matter of hours.
>
> I guess this is due to the "industrial" requirements of many Qt users,
> though in my small experience I already saw the following happen:
> * business B uses a tech A for years and lobbies against big updates and
> breaking changes "for stability concerns"
> * developers of tech A want to keep the business as a client so they limit
> changes to the max
> * developers at the business B, etc are slowly getting fed up with working
> with software full of old practices and legacy bugs
> * in the meantime some other shiny new tech is being developed by random
> guys on a github repo
> * tech debt at business B accumulates, developers are even more fed up when
> they look at the new tech which looks oh so shiny
> * one day a dev of business B does a proof of concept of a remake of their
> software with the new tech and show it to B's business owner while telling
> them "it took 1/10th of the time it takes to develop with tech A!"
> * business B decides a complete switch from tech A to new tech and the
> company that develops tech A gets less and less clients and are reducted to
> using predatory practices to keep their clients.
>
> This could (maybe, maybe not...) have been averted if tech A had more
> ambitious updates that did not fear doing breaking changes from time to
> time to make the overall thing easier to use.
>
> Best,
>
> -------
> Jean-Micha?l Celerier
> http://www.jcelerier.name

Jean,

An interesting perspective. On the PC side of life, I have no doubt it 
is true. On the big systems side of life, it will never be true. Y2K 
happened because management kept saying "oh we're gonna replace that 
system" whenever developers said "we need to fix this." All of the 
replacement systems failed so a mad rush of patching occurred. Another 
mad rush will happen around 2027 if you feel like doing COBOL. Don't 
know why, but 2027 seemed to be the hack year chosen for most entry 
screens which did not have room for a 4 digit year. Wanna know why it is 
going to happen? "Oh, we're gonna replace that system."

Core business systems get replaced under these conditions:
1) The company drops an entire business line. (The Chicago Stock 
Exchange got rid of its trading floor, moving to a completely automated 
system without specialists or any floor personnel. The "temporary" 
trading floor system which started out on the PDP in the 1970s, moved to 
the VAX in the 1980s, the Alpha in the 1990s and the Itanium processor 
in the 2000's finally hit the end of its "temporary" life.)

2) The company is eaten by a larger/more cash flush corporation which 
forces them onto the corporate system.

3) The hardware and OS vendor goes out of business without any third 
party emulators. Think Wang computers and even Singer computers. If you 
want more modern examples, Oracle is pulling the plug on SUN Sparc so 
systems which relied on the massive threading capability of the platform 
have to either die or be reworked to run on lesser platforms.

Software is used to run a business which makes money doing something 
else, so there is no incentive to jump ship. Technically, you can 
continue to run long after the hardware and OS vendor has went out of 
business as long as there are third party hardware maintenance companies 
with a stock pile of parts. I know one CAT location is rumored to have 
used a certain model PDP to control all its drilling and milling 
equipment at their Aurora, IL location. Story goes when DEC announced 
they would make no more CAT went out and bought every used one they 
could find, parked them in a storage location and cannibalized them for 
parts for the next twenty some years. They are in the process of closing 
that work or the plant down, have slowly been for years. That is how the 
PDP's eventually stopped being used.

On the PC side of life, we have similar situations for both industrial 
and medical. Industrial test equipment (and there is a lot of it) needs 
to be stable and certified. When it is going into some kind of assembly 
line or plant, the buyer wants the _exact_ same interface on each unit 
even if it does different things based on where it is in the line. They 
want to be able to move factory workers at a moment's notice.

In the FDA regulated world, you have the clinical trials process each 
change must go through. For surgical robots that involves a bunch of 
cadavers first for your own internal testing, then for FDA approval and 
whatever else the FDA wants done. (Not as easy as it might sound. You 
have to wait for people to die with the organs you need in their 
original locations __and__ they have to have willed their body to science.)

Personally, I do not remember the FDA testing and approval process for 
this device:
https://www.welchallyn.com/en/products/categories/patient-monitoring/vital-signs-devices/connex-spot-monitor.html

I remember I was told at some point, but my job was only to write 
roughly half of the C++/Qt UI code adhering to all of the FDA 
development regulations, fixing anything the independent QA team found.

In the medical device world, you have automatic updates turned off in 
your Linux development environment. That "move quickly and break things" 
shit causes millions of dollars worth of problems. Sometimes it even 
leads to products which get onto the market then appear in those late 
night personal injury lawyer commercials.

While I don't doubt you have seen what you say, I would like to point 
one thing out:

* developers of tech A want to keep the business as a client so they limit
changes to the max
* developers at the business B, etc are slowly getting fed up with working
with software full of old practices and legacy bugs


Developers of tech A did _exactly_ what Qt is doing now which means they 
are doing it wrong. "Limit changes to the max" means they focused on 
shiny new features while letting bug reports rot. I submit the phrase 
"legacy bugs" as proof. While "old practices" may or may not be 
changeable, they do not drive a business from a technology. I just went 
to indeed.com in a browser I had never used to get there. Searched for 
"cobol programmer" without any location.

Full-time (218)
Contract (85)
Part-time (10)
Temporary (6)
Commission (2)
Internship (1)

"fortran programmer" no location
Full-time (43)
Contract (3)
Part-time (2)
Commission (1)
Temporary (1)

"forth programmer" no location
Full-time (95)
Contract (7)
Part-time (4)
Commission (2)

While many of today's "script kiddies" can't be bothered to learn 
disciplined software development, enough can and do. I chose those 
languages because phone and Web people consider them dead tech. They 
seem to ignore the fact COBOL runs almost every (probably every) payroll 
system on the planet. FORTRAN is still massive in the scientific and 
research communities because it has capabilities no other language 
possesses. At least the commercial proprietary platform versions do. The 
GNU version cannot have more capabilities than the C language back end. 
(Yes, I know they p-compile things to the GNU language and that gets 
compiled by the back end, but the original back end was for the C 
compiler...no need to veer off in minutia.)

Believe it or not, FORTH is still used in a _lot_ of embedded systems 
__and__ AI.

indeed.com sucks when it comes to searching for ADA. I see it constantly 
in the DOD/military contractor postings, but you just can't search for it.

Sorry, I guess I did veer off a bit.

At any rate, the powers that be behind Qt have chosen to add "sexy new 
features" at the expense of bugs. Mostly this is to chase new markets 
which will have a catastrophic effect on the product. You cannot serve 
multiple masters.

QML was a mistake of biblical proportions. I've heard all of the bogus 
justifications about "further segregating interface" blah blah blah. The 
truth is script kiddies don't have the discipline to learn C++ so they 
tried to change Qt into a script kiddie friendly product. Ironically 
they did it to chase the phone market. I say ironically because QML is a 
yuuuuuuuuuuuuuuuuuuge resource pig.

http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/

Frack! When I migrated to a new host the video player plug-in wasn't 
compatible. I need to poke around for a new one tomorrow to fix that 
post so you can see the indescribably wretched performance of QML on a 
Pi 2 vs. the same application compiled from C++ and widgets. You can at 
least pull the code down and try yourself.

QML's massively intense resource consumption inhales battery life so the 
choice of app developers seems insane. Idiot phones are now having 
battery life measured in minutes while flip phones have about 2 days 
worth of talk, not stand bye, time.

Personally, I've never seen the point in chasing the phone market. Your 
app has the lifespan of a fruit fly. The next forced out 
Android/Apple/whatever update will break it. Windows Mobile has been 
abandoned. Google is dropping Android, moving to Fuchsia (sp?) in the 
next year or so. Ubuntu is also moving to Fuchsia, abandoning Linux. 
Windows isn't even going to be Windows 2 years from now. It is going to 
be a Microsoft front end on top of what used to be Ubuntu Linux. They've 
already started the process with Windows 10. Adding insult to injury 
phone developers push for a zillion "cool new features" in Qt adding 
even more bugs to the pile of bugs currently being ignore while 
developers slave away trying to add those "cool new features."

In short, they are "developers of tech A" in your example. The existing 
medical, industrial and agricultural device industry using Qt (massive 
by the way) will not be able to continue using the tool because the 
pursuit of "cool new features" blocks the bugs they need fixed. Today's 
phone operating systems will cease to exist within two years, requiring 
a soup to nuts redevelopment of Qt adding more bugs.

Personally, I don't know what Apple is moving their iPhone to, nor do I 
care. I know that every phone OS vendor is seeking "one ring to rule 
them all" right now. A single OS for Phone, laptop, desktop, server, and 
IoT. Ubuntu had to punt on their phone

http://www.techradar.com/news/canonicals-dream-for-an-ubuntu-phone-is-dead

so they have their own fork of Fuchsia (sp?)

Unit was a grotesque desktop so I'm kind of glad it all failed. Now if 
Neon could fully divorce itself from Ubuntu...

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171008/0a41342b/attachment.html>