mtbc: maze I (white-red)
[personal profile] mtbc
When I was starting out in computing there was much elegant beauty to behold in it: feats of engineering that appeared carefully crafted and whose creators could be proud so I was easily attracted into learning more. For instance, the sound and graphics chips in the Commodore 64: they were easy to program but able to deliver far more than one would have expected, even more than the designers had planned. The later Amiga had lovely hardware too, again for its time. Or, some of the business systems I worked with in transitioning local clients to the new IBM PC: the software on a Z80-based predecessor from Wang that I worked on was actually really good, being clear and functional and well-behaved, making it a breeze for me to learn my way around them and extract the data ready for transforming into the new system. Throughout the 1980s it was a surprise for me to find bugs in serious business software.

Coincident with the rise of Microsoft Windows I have seen software quality go down. Now it is entirely normal to run into bugs. It is also normal for software to frustrate me: it insists on doing something I don't want or I can't get it to do something it clearly ought to be able to. From within the sausage factory we see a complex enough software stack that largely we sign off on changes when they seem to work. There is no sense that the design is clean and clear enough that we would be surprised if it did not pass QA after all. There may be intermittent failures but nobody is quite sure why. Software development starts to feel less like art and more like wrestling. Modern hardware is little better: routers crash and need power-cycling, patches to expensive firewalls break traffic in odd ways, enterprise storage is flaky, etc.

It isn't all bad. Technologies ranging from OpenBSD to Haskell, while building on the shoulders of giants, are laudable projects gaining in currency, the latter thanks in part to Microsoft Research. Still, I wonder what changed.

(Haskell is a nice example: in my code I can use phantom types to pass around integer IDs of objects such that compile-time checking ensures that I never mix up the ID of one kind of object with that of another but also that the type-checking overhead is compiled out of the native executable; in the real world of the mainstream we are still accepting strings from web forms and not using strict typing to ensure that they can never be confused with a string that has defensively been safely escaped. It seems to me like many common modern bugs should have been professionally engineered away years ago.)

It feels like most software developers now care about little more than getting things working well enough so that their employers can sell them comfortably. The developers wanting to use their mathematical gifts to create systems that are both solid and flexible are largely dwarfed or otherwise out-competed by the many who just want to deliver something that appears to work sufficiently well that everybody gets paid and management either do not appreciate or do not care about the difference.

Maybe the change is partly in the user community: the perception or expectations have changed somehow: users no longer realize how good things could be so they tolerate substandard software enough to keep on paying and the providers have learned that they can get away with this. Whereas, I find it positively outrageous that technology is of such low quality that my smartphone can take a couple of seconds to offer any visual indication that I successfully clicked an on-screen button then take my subsequent attempt to click it as my clicking the button that then pops up in its place. This really is basic stuff.

I don't have any answers, I think it's just how the world works. I would look at retreating to high-assurance systems but look at the Department of Defense's move away from Ada or Ericsson's from Erlang: I think the only refuges are in the past. I could be frustrated to know that modern computer systems are typically no longer built anywhere near as well as they could be but I instead find myself grateful to be able to recall a time when it was normal for them to be both useful and reliable.

Date: 2017-06-15 06:13 am (UTC)
aldabra: (Default)
From: [personal profile] aldabra
I'm not sure the fault lies with the developers; I suspect strong management pressure not to waste time tweaking once something broadly works (and in a marketplace that outcompetes doing it right).

My dishwasher doesn't acknowledge that I've pressed the start button until after I'm out of the kitchen and halfway up the stairs, typically. This is a confounded nuisance, because if it *doesn't* start when I'm halfway up the stairs I have to come back down to find out why not. What is this delay of tens of seconds before it starts doing the thing, and how difficult would it be to have a beep or a light or something to demonstrate that it's thinking about it?

Date: 2017-06-15 09:30 am (UTC)
aldabra: (Default)
From: [personal profile] aldabra
I think sufficiently mathematical (and adequately trained) minds are rather more expensive than bodging. And some of those mathematical minds have a different vision of beauty: my first IT-ish job landed me with 10,000 lines of C to maintain, and Kernighan and Ritchie and the obfuscated C competition which I was meant to teach myself C from first, and the 10,000 lines were very sparsely commented but I particularly remember "I bet you can't see why I've done it like this." (They decided he was too talented for the company and he had left before I arrived.)

This bloody printer at work does that too. You send something to print and you walk to the other end of the office to pick it up, and the printer has done nothing, and you don't know whether to wait for the printer to wake up or go back to your desk to see whether Windows has produced a confirmation box or an error since you got up and left.

And they've changed this set-up at work such that when I sit down and shake the mouse it doesn't turn the monitor back on straight away, so I have to stop and see whether it has turned itself off more throughly, which it hasn't. Grr.

Date: 2017-06-15 01:20 pm (UTC)
emperor: (Default)
From: [personal profile] emperor
I have very little maths, but I do sometimes struggle to persuade management that it's worth fixing the underlying problem (e.g. a misbehaviour of cron if LDAP is unavailable on start-up) rather than simply putting in a workaround (and an alert in case said workaround fails).

Date: 2017-06-15 02:32 pm (UTC)
mindstalk: (Default)
From: [personal profile] mindstalk
One difference is much more powerful computers, that support a much more complex stack. And mostly doing non-critical things.

Date: 2017-06-21 10:12 pm (UTC)
goldibehr: (Default)
From: [personal profile] goldibehr
I've been trying to figure out a good reply to your post.

One big contributor to this quality problem is that we're forced to use these big libraries/frameworks, and it's hard to always be aware of the assumptions built into them. Even good developers can end up with bugs because of this.


mtbc: photograph of me (Default)
Mark T. B. Carroll

September 2017

      1 2
3 4 5 6 78 9
10 1112 13 14 15 16
171819 20212223

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 10:26 am
Powered by Dreamwidth Studios