The Jargon file has definitions for programs on the higher end of the scale. See robust and bulletproof.

Jargon File

Across the world, desktop support staff try to port ancient, barely-documented and supposedly-vital applications by defunct vendors from Windows XP to Windows 7, and hope April never comes.

I have some big-name, heavily-promoted software that I would describe as buggy. As in, it crashes or hangs about every 20 or 30 minutes, in one of five or six ways, most of which have to do with the way they're meshing a database with Visual Basic and doing it rong.

linnen @1:

The Jargon File looks useful, if perhaps a little more white-box (how the systems are coded rather than how they're running) than my assessments tend to be.

Alas but unsurprisingly, I seem to spend more of my time and energy making fine distinctions on the lower end of the scale. Not so much because that's where all my systems are as because that's where that subset of all my systems that takes up all my time are.

You function, then, as an insectivore.

abi @4:
True. It was written more from the viewpoint of programmers, specifically hackers, than from the system admin. Not to mention that the file has not been updated in a while.

Example;
lithium lick: n.

[NeXT] Steve Jobs. Employees who have gotten too much attention from their esteemed founder are said to have ‘lithium lick’ when they begin to show signs of Jobsian fervor and repeat the most recent catch phrases in normal conversation — for example, “It just works, right out of the box!”

One used over here is "fixable"...
In the sense of "If it ain't gone wrong, don't fix it!"

"Fix" is spelled with a "u".

I see quite a few bug-like events in one piece of software, which is part of a server/client system running over the internet. Some of the basic design decisions for the server-client communication were, shall we say, somewhat sub-optimal.

A lot of the software is stable, but the overall effect is scruffy, verging on buggy. When things do start going wrong there are some very clear patterns.

Some programmer has just spent a couple of years sorting out some of these fundamental problems. They have finally caught up with Section 8 of RFC2616 — HTTP implementations SHOULD implement persistent connections.

RFC2616 was published in June 1999, some 4 years before this software project went live.

You have to wonder if some of the brilliantly creative young programmers, who change the world with their concepts, are all that practical. Would a bit more rigour on the initial design and programming have paid off in reliability and ease of maintenance?

But who, all those years ago, expected a computer product to last for a decade? Even with some of the easy hacks crashing headlong into Y2K all around them. Windows had the year shown as a fixed string, with the last character being an integer added to a constant and converted to ASCII.

199:: the new millenium!

This brings back fond memories of our merger a few years back, with an elastic definition of 'fond'. The problem is that the users had the final say even though the system was a black box to them, and to them all bugs were evaluated as we-are-DOOMED!!!

Science fiction scenarios in which the people all vanish, but automated systems are still working, make me laugh and laugh. The time until one server goes sideways, and the dominoes start falling, won't be long. That's partly why I wasn't worried about Y2K. Something's going to crash? Of course it is! Software crashes all the time, and we fix it.

My favorite way to describe things at my last company was duct tape and bailing wire. That's what you get when a major IT outsourcing company uses a MS Access, Excel and VB for major operational and customer-facing metric reporting. Needless to say, this also involved the last 4 adjectives on the above list with a certain level of frequency. Oh, and the date for the new BI software implementation was always next August. I've now been gone from that company for 5 years, so perhaps that last prediction finally became truth. Maybe.

I work in QA.

If out product works perfectly, you notice (or not) that SyFy or AMC or whatever is playing an advertisement for the car dealer or carpet installer downtown.

Less perfectly: There will be a split second of another advertisement -- usually for something like the Snuggie, asbestos lawsuits, or discount catheters -- before the local advertisement plays.

Not at all: You see the Snuggie or catheter ad.

The REAL user notices, though. They (your friendly local cable franchise) has lost out on ad revenue. Unforgiveable!

Our challenges is to make a server -- vetted hardware, customized OS releaser, and our software -- that is able to sit on a rack, virtually unseen and unheard, for months on end. Ads and schedules, set up in a sales office using front-end software are loaded automatically, and things happen.

The challenges come from failing hardware, and the complex gear that talks IP over the coax network.

One of the things we keep saying at work is "things always breaks". When you do things at a sufficiently large scale, rare events become common.

One relatively easy exercise would be to estimate how frequently you need to swap disks of you, say, want to store 1 PB of data.

You can easily get 2 TB disks. So, 500 of those has you sorted. But, as things always break, you should probably replicate, so let us go for 3-way replication (because that way, we can probably avoid losing data). So, that it's 1500 disks. If we assume that disk failure are uncorrelated, and a disk typically lives 2-3 years, we are looking at losing 1-3 disks per day.

Things ALWAYS break.

And a system that can't tolerate that scares the shit out of me. Partly because their design speaks to an experience where failure isn't an option.

I learned one thing you never say is "Hey, [name of program] hasn't crashed all week!"

Bug anonymizing:

Call comes into the customer service group; they pass it on: "I was trying to X, and it didn't work!"

One of these days, I will get the CS people to ask the question: "OK, what exactly happened?"

C. Wingate: One of the parts of my tech-support job I actually liked (although sometimes I got sick of it, too) was the mental/visualization exercise involved in getting from "My data is broken!" to exactly what's going on. There is a lot of skill in the psychological manipulation of getting the customer to realize you're not wasting their time by running through really basic tests (that they see as useless, because they didn't fix their data), on top of the mental gymnastics of seeing, in your mind's eye, what's on their screen as they describe it and do the things you asked them to do.

One of the things we had to train newbies in (because almost all our new hires came in fairly computer-literate and computer-comfortable) was how to describe to THE CUSTOMER which part of what they're seeing is important, and what we need to know about it. Because it's a multiple-translation, from my own internal checklist of prioritizing what really-wrong things are most likely that look like what they have, then through my mouth to their ear, from their ear to them understanding (enough of) what's on their screen, and then the absolutely amazing ways customers came up with for describing stuff. Seriously. "Shit my kid says" levels of awesome/horrible/I-need-a-drink-now. :->

Late in the training phase, we always had another tech do a fake call into a newbie (we did a lot of specimen calls in training) as a customer I'll call Mr. K, who was interesting not only because he had a setup that was once standard and now (well, the 'now' of then that I'm talking about) extremely rare, but because you had to tell him, every time, whether it was a right mouseclick or a left mouseclick. Every time. Oh, and his main machine running our stuff was not connected to the internet (for security), so you not only had to walk him through diagnostics and reinstalls, but how to sneakernet the files he needed from his internet computer over to the one running our stuff. I treasure the memory of the long afternoon I spent trying to fix his server, only to eventually discover that the floppy disk (!!! Even in 1998 that was weird) drive on his internet-facing computer was sufficiently posessed by malefic spirits that any disk put into it came out similarly borked and would never work again in any other machine (or that one).

He was absolutely brilliant in the field our software aided him in practicing, but he was also about 70 years old (and had been working in his field since his teens), and very self-conscious about being "an idiot" about computer stuff. Providence be my witness, if I am as flexible as he was, when 70 years old I achieve, about new and scary world-changing technology, I WILL BE ECSTATIC. But it made him a really good graduation exercise for new techs, because it gave you practice working with a client who really wouldn't let you skip any steps at all in your description (because without instant-by-instant guidance he was utterly lost).

I am always annoyed, and yet somewhat understanding, when I interact with tech support over the phone and have clearly ended up with someone who's only been taught how to use the decision-tree and doesn't actually own all the diagnostic knowledge necessary to deal with it when the problem is not horses or even zebras, but coconuts. It's HARD to train that. Even when you have new hires who are as conducive as possible to it, it takes time and effort, and a lot of companies aren't willing to pay for that on all their staff. And, let's face it, over 60% of all calls to any given tech support line are going to be from their most common 3-6 problems. Ours certainly were. The trick is running the other 40% of callers through your let's-just-be-sure-because-it'd-be-embarrassing-if-it-were-something-easy checklist without alienating them about your company.

C. Wingate, #16: On the one hand, yes, I fully understand how annoying that is. On the other, there are occasionally sharp words between myself and my partner because I go back to his office and say, "I'm having a problem with X," and he snaps out an annoyed, "What KIND of problem?" when that was about to be the next sentence. I consider the "problem with X" formation or its equivalent to be a subject header, so that I'm not asking him to magically know what I'm talking about when I launch into the middle of the conversation.

Not all users do this, I know. But he and I have had this conversation, several times, and that contributes to my own annoyance when it happens.

This is what the Australian social security system runs on:

There are mainframes (which used to be redundantly placed in Perth, Adelaide, Sydney and Canberra, to cover the four time zones, but have now been consolidated to the point where they're now redundantly placed in two suburbs of Canberra. The two data centres are about thirty minutes drive from each other on a really rotten day[1]). These hold the vast database which contains data about just about everyone in Australia - possibly the only people they're missing are the scions of the very wealthy families who have never bothered to claim any kind of welfare payment, and the children of anti-government extremists (of whom we have very few). So, there's data on there about the majority of the Australian population[1].

I'm not sure, but I think the servers are still speaking a bastardised version of IBM JCL.[1]

There are the individual office servers, which used to be running Netware (back the last time I looked, in 2006) but which are now most likely Windows all the way. The email system is still Lotus Notes (it was cheap about 20 years ago[1], and now Centrelink is one of the organisations keeping them in business). Lotus Smartsuite used to be the default office suite (thrown in free with Blotes[1]) but the demands of inter-agency co-operation were gradually resulting in more and more users getting licences for Microsoft Office. So I suspect by now the agency has given in and gone for MS Office as their default office suite. The PCs in the offices mostly run Windows, loading user profiles from the local office server, and thus theoretically allowing hotelling. In practice, the staff get their desks and cling to them like limpets. However, the profiles are still stored on the server and loaded down to the PC on login, and stored back to the server on log out[1]. Back when I was working in their tech support section, our single most frequent "cause" for trouble tickets was profile issues.

Just recently, they've started adding in tablet PCs to the suite of different IT bits and bobs which are vaguely working together to provide Australians with our social security infrastructure. They're Apple iPads[1], and thus speak an entirely different dialect of hardware and software design. They're used to interact with the scheduling system on the mainframes, via the office servers. It's rather like having someone who speaks only Mandarin Chinese talking with someone who speaks thick Glaswegian English, as translated by someone whose primary language is Arabic[1].

To paraphrase Dr Johnson, the fascinating thing about the Australian social security system is not that its IT infrastructure works so well... it's that it works at all.

[1]. [2].

[1] *sigh* Yeah.
[2] Most of my information about the specifics is a bit out of date - I last worked for the agency in question in 2011, and I last worked for them in a technical role in 2006. However, the overall generalities are pretty constant.

Abi, do you have vocabulary to distinguish the fragility of a Gingerbread House from the fragility of Prince Rupert's Drops?

In the GBH case, local failure is not only possible, but typical: little bits are liable to break off easily, but without affecting the central architecture. In the case of PRD's, fragility is necessarily systemic: there is only one failure mode, and it affects every atom of the previous entity. You can't break half of a PRD.

oldster @20:

In my experience, PRD architecture's failure mode is not fragility but brittleness. That's kind of the essence of brittleness—it looks OK, but it's one (probable) failure away from complete catastrophe.

Indeed, I'd say the GBH/PRD distinction is pretty much the same as the fragile/brittle one.

Thanks! That helps me to understand your lexicon.

After which, I suppose it's a judgment call whether to put fragile or brittle higher or lower on the scale from "clean" down to "comprehensively f'ed".

On first thought, I'm inclined to reverse your ordering; on second thought, I suspect there's no right answer, just as there is no right answer to the question, "which is the greater risk, lightning strike or backache?" There are (at least) two factors that go into risk assessment, one of which is probability of occurrence, the other of which is severity of results if it does occur. Backache is a (relatively) low-severity, high-probability risk, whereas lightning strike is a high-severity, low-probability risk.

So the fragile ones may be highly likely to suffer damage, but the damage will be minor, whereas the brittle ones are very unlikely to suffer any damage at all--but if they do, then it'll be fatal.

When there are two orthogonal factors of assessment, there's no point arguing over where to put them on a linear scale.

In my experience all substantial systems are at least a bit awkward use and suffer from various glitches and bugs in operation.

As far as I can tell, this is because users care more about new functionality than they do about elegant well-rationalized systems that are utterly bullet-proof. And those priorities filter through the system manager to the account rep to the product manager to the developers. So the users end up with systems that do a lot, but are hard to set up, awkward to use, and somewhat unstable.

oldster @22:

I did say it's not actually a linear scale.

I'd say the main reason I put fragile below brittle is that fragile systems tend to dip in and out of fucked state, depending on whether the duct tape is peeling off again. It's a porous border, so I kind of instinctively made them neighbors.

But one could as convincingly argue that a system that's keening is at least giving you warnings that it's time to sort things out. Brittle ones can lull you into a false sense of security, then leap straight to comprehensively fucked in a heartbeat.

(Backache is more of a buggy or scruffy problem. The fragile/brittle distinction is, what's worse, a slow, progressive infection that kills you, or a heart attack that kills you? The individual impacts of the higher-probability risks of a fragile system are lower, but their cumulative impact is the same: fuckedness.)

@24

Good heavens, you did. And I simply failed to notice it. Apologies.

My backache is actually the result of scruffulous humors. I can't say it has ever led to the end-state you describe, however.

Someone here recently gave us a very nice Henry Reed parody; anyone willing to offer "this is the naming of bugs?"

Elliott Mason #17: only to eventually discover that the floppy disk drive ... was sufficiently posessed by malefic spirits that any disk put into it came out similarly borked and would never work again in any other machine (or that one).

Back in my college days, a friend of mine was sysadminning around MIT -- minicomputers with big old drives the size of a washing machine, with removable disk packs that you'd swap around. If your computer couldn't read the disk, that could mean the drive was broken, or the disk pack was damaged. To tell which, you'd have to try the pack in a different, known-good drive, and/or try a known-good pack in the original drive.

And then, one day he ran into a contagious disk flaw: The original drive would damage any pack put into it, such that the pack would then damage the next drive they were put into, and those would then damage the next pack put into them.... He estimated he'd trashed at least $40,000 (mid-1980s) worth of MIT's equipment before figuring that one out....

Oldster @26: The naming of bugs is a difficult matter.
It isn't just one of your holiday games ...

#26 ::: oldster, ...a very nice Henry Reed parody

That was Mongoose, one of our many talented poets.

This seems more about systems (with one or more bugs) than about bugs per se.

When I was last doing QA full-time, we had pretty boring categories for individual bugs. In the best system, their severity was Low, Medium, High, or Critical (that last meaning "renders the entire system mostly or entirely unusable" - what's called a Sev1 in Production). The rule was that a release could not go live with known Criticals or Highs. Of course, in practice a relatively obscure High severity bug might sneak in.

The Priority of a bug was the number of the release in which it should be fixed. I liked that, because it let me design my main testing protocol (that is, between basic acceptance testing (which when it fails results in bouncing the release back to Dev for another try) and regression testing) for the release prior to actually getting the release.

That was back when you got a Functional Specification from your Developers, had a walkthrough, wrote your detailed Test Plan based on the Functional, had a walkthrough of that, got signoff from everyone that if it passed all those tests it would fulfill the Functional, and set in to test once you got the release.

Last I saw in an organization where I worked, the Test Cases looked pretty auto-generated to me, and they certainly relied on automated testing for more than Regression. The final result was some pretty buggy software.

But I wasn't in QA at that organization. I was in Tier II Support. I did a lot of QA-like investigations in that job!

Oh, "scruffy" is an eminently sensible and useful word. Much of the software that I'm involved with is scruffy. I hope you don't mind if I borrow it. (Much of my software is also well-described by today's XKCD.)

Whenever I sit down with a user, I am always amazed and humbled by the workarounds they develop. They'll put up with far, far more than I would in order to get their jobs done.

Kellan @ 31: I think it happens largely because for many users, they don't understand the works inside very well, and therefore don't know which things are easy and which difficult, or even any solid criteria to make guesses from. Things I can fix in 5 minutes, people put up with for years, while things that look like they *should* be fixable in 5 minutes can't be done at all. From their perspective, there's little to explain which ones are in which category.

It makes me want to cry. I'm not a terribly political animal, generally, but computer user rights are one of the few things I would be an activist about. Computers are too damn hard -- we need better public resources for minor to medium computer help, for those who don't have access to a pet geek like me. Whereas I know enough about how the system works to know how to put it to work, and to have very little patience for things being unnecessarily difficult for lack of proper tools.

#29--
Thank you, Carol. Mongoose it was, and talented it is.

Our bug tracking system rates severity, and priority.

Sometimes a very bad bug will be in a rarely-used feature, so the severity will be high and the priority (to get fixed) will be low.

I'm trying to think of other terminology.

A "Day One" bug is one that has been around since the Before Times that hasn't been hit until now.

"Alignment of the Moons:" An extremely rare circumstance that causes a bug to recur.

"Wrapped around the axle." The server has gotten into a thoroughly screwed state. Think Isadora Duncan.

"Memory leak." That is a standard term, AFAIK. A memory structure created during standard operation doesn't get torn down afterwards, so the memory used by the process grows and grows. A program can also leak file descriptors, and the limit allowed by the OS gets hit.

Yes, "memory leak" is indeed a standard term, coined, AFAIK, in reference to early Windows systems which were particularly plagued with the problem due to Windows not have a real garbage collection system, unlike various and assorted *nix systems. The problem was particularly egregious if one closed a program by clicking the "x" rather using the pulldown menu and clicking "Exit."

So, does anyone one know if Windows ever got proper garbage collection? Programmers seem to have gotten better at writing applications that don't leak memory (not perfect mind you, just better). Of course, that just leaves room for new and interesting bugs.

Kellan Sparver @ 31: Whenever I sit down with a user, I am always amazed and humbled by the workarounds they develop. They'll put up with far, far more than I would in order to get their jobs done.

Omigod, yes. Unpleasant as it is for the individuals involved, I think it's good when developers get stuck being on-call for a while. Suddenly all sorts of things get fixed!

"Memory leak" is in fact a term of art, but has nothing to do with Windows in particular -- I can't find an etymology citing the term's earliest use, but I would wager good money it predates Windows and microcomputers more generally.

Jargon file: memory leak
Wikipedia: Memory leak

Garbage collection qua garbage collection isn't something which is usually implemented at an OS level -- computer scientists are more likely to speak about garbage-collected programming languages. Even garbage-collected languages can have memory leaks, the specifics of which vary depending on how the language implements garbage collection. (Circular references and reference-counted garbage collection being a popular bad combo. More detail available upon request.)

In general, though, you're right that the rise of garbage-collected languages has helped reduce the incidence and severity of memory leaks in practical use, as have better programming practices (Resource Acquisition Is Initialization, eg.), better memory segmentation at the OS level, and generally having more memory available so it's not such a bad deal to waste a little.

"Memory leak" is in fact a term of art, but has nothing to do with Windows in particular

Garbage collection qua garbage collection isn't something which is usually implemented at an OS level

Indeed, but Windows had a lot to do with memory leaks! (Or more generally, resource leaks.) Remember that Windows developed directly out of DOS, which was originally not even a multithreaded system, much less a time-sharing one.

The early Windows versions (basically, at least up to NT) had a lot of system-shared resources, and was pretty bad at cleaning them up when a program exited. Especially if it hadn't shut down on its own initiative -- and back then, that "close window" button represented an OS override (which didn't always work), with a completely different program path than an "Exit" menu item would use.

37/38
I think the program that I'm having buckets of trouble with is one that could use better garbage collection - it's been around since the late 80s, roughly, and it 'runs out of memory' way too often, for something that has lots of memory to play with. It also uses more than it really needs to, compared to the other program I have which does the same stuff and uses about half as much RAM.

I am reminded of one game written for the Amiga where Satan had clearly been on the development team. We sold a ton of 'em, then about half came back as unrunnable. About 60% of those copies worked on some computers at the store but not others. It turned out that the developer decided to write their own DOS which loaded when you booted the disk. Unfortunately they'd also developed their own copy protection system, which looked at how the heads tracked the disk. Which would have been fine, but their drives had been slightly misaligned so the DOS wouldn't load unless the heads on your drive were misaligned the same way.

There are reasons I'm not a purchasing agent anymore...

#27 Dave Harmon,

The proper algorithm to follow is to put an erased disk pack into the questionable drive. If you can't write and read, stop! Only the first operator who ever encountered this problem had an excuse.

I had a co-worker who did a similar stupid. He was programming one time programable micro-processor chips. On the first insertion he bent pin on the programmer. The first device and all the rest of our stock failed to program and were destroyed. It never occurred to him to stop. Don't ever let a programmer do a hardware task.

oldster @22: In risk management, we call probability of occurrence "likelihood", and severity of results "consequence". We then plot likelihood and consequence as two axes on a risk matrix, which has squares with each square given a severity from "meh" to "OMFG".

The number of squares on risk matrices varies: some are as small as 3 × 3 (i.e. 3 possible likelihoods; 3 possible severities); some are as large as 10 × 10.

Sometimes we have several different risk matrices for different kinds of risk: one for dollar loss (caused e.g. by lost production), one for injury and/or death, one for environmental damage, etc. Sometimes we convert those all to a common currency, either quantitatively or qualitatively, and put them all on one matrix.

Risk matrices on Google (including images)
Risk matrix on Wikipedia

The naming of bugs is a difficult matter
It isn't just one of your holiday games
You may consider us all mad as hatters
When QA gives the bugs infinite names
First is the name of the classification
Logic or run can take the blame
Memory and old compilation
These are the types of software bug names
There are also the names applied to the hardware
Badly soldered chips and misaligned frames
Missing connections and broken components
Concrete, physical, touchable names
Then are the names of the QA/Dev team
Sys2, WinA, ThisNeedsAName
A clue for where and how to recreate
So the problem discussed will be the same
Colleagues may use something more creative
Written in codes or old l33t games
The better to describe ongoing problems
Or who on the dev team gets to shoulder the blame
Last there are names released to the public
Usually safe, unthreatening a completely forgettable
Alpha-numeric and quite dignified
Never hinting at the errors regrettable
And those who have solved the ticket with pride
If you see an analyst in quiet contemplation
Sitting with tea and solitaire running
It's likely their mind is occupied with their current frustration
The naming of which is best if it's punning
The name should be worthy of team acclamation
Describing the problem, the product, and never, ever, hinting
At how much the system, the product
Is fragile, brittle, and
Just about
Fucked.

There's one nit I'd like to pick with this progression. It appears to assume, implicitly, that systems start out clean and go south. In my experience, systems get put into production somewhere between brittle and scruffy (or perhaps a somewhat-borked version of stable where everything that works, works, and the things that don't work at least don't destroy anything else).

After a while, that turns into what appears to be clean or stable, but is actually brittle because the stuff that hasn't blown up yet also hasn't been fixed.

paul, it's a classification, not a progression. While it's arranged from OK to terrible, there's no implication that a system will progress through the different classes over time.

I never could find who the author was, but here it goes...

Once upon a midnight dreary, fingers cramped and vision bleary,
System manuals piled high and wasted paper on the floor,
Longing for the warmth of bed sheets, still I sat there doing spreadsheets.
Having reached the bottom line I took a floppy from the drawer,
I then invoked the SAVE command and waited for the disk to store,
Only this and nothing more.

Deep into the monitor peering, long I sat there wond'ring, fearing,
Doubting, while the disk kept churning, turning yet to churn some more.
But the silence was unbroken, and the stillness gave no token.
"Save!" I said, "You cursed mother! Save my data from before!"
One thing did the phosphors answer, only this and nothing more,
Just, "Abort, Retry, Ignore?"

Was this some occult illusion, some maniacal intrusion?
These were choices undesired, ones I'd never faced before.
Carefully I weighed the choices as the disk made impish noises.
The cursor flashed, insistent, waiting, baiting me to type some more.
Clearly I must press a key, choosing one and nothing more,
>From "Abort, Retry, Ignore?"

With fingers pale and trembling, slowly toward the keyboard bending,
Longing for a happy ending, hoping all would be restored,
Praying for some guarantee, timidly, I pressed a key.
But on the screen there still persisted words appearing as before.
Ghastly grim they blinked and taunted, haunted, as my patience wore,
Saying "Abort, Retry, Ignore?"

I tried to catch the chips off guard, and pressed again, but twice as hard.
I pleaded with the cursed machine: I begged and cried and then I swore.
Now in mighty desperation, trying random combinations,
Still there came the incantation, just as senseless as before.
Cursor blinking, angrily winking, blinking nonsense as before.
Reading, "Abort, Retry, Ignore?"

There I sat, distraught, exhausted, by my own machine accosted.
Getting up I turned away and paced across the office floor.
And then I saw a dreadful sight: a lightning bolt cut through the night.
A gasp of horror overtook me, shook me to my very core.
The lightning zapped my previous data, lost and gone forevermore.
Not even, "Abort, Retry, Ignore?"

To this day I do not know the place to which lost data go.
What demonic nether world us wrought where lost data will be stored,
Beyond the reach of mortal souls, beyond the ether, into black holes?
But sure as there's C, Pascal, Lotus, Ashton-Tate and more,
You will be one day be left to wander, lost on some Plutonian shore,
Pleading, "Abort, Retry, Ignore?"

We had serious memory leak problems on UNIX in the late nineties. You wouldn't think a hundred bytes would add up to much today, but disks were way smaller back then. It doesn't help when they're all accumulating in the /tmp directory and it's its own file system.

Sisuile beat me to it, but here's another take:

The naming of bugs is a difficult matter
It isn't just one of your holiday games
You may think at first I'm as mad as a hatter
When I tell you a bug will have THREE DIFFERENT NAMES
First of all, there's the name that the database uses
Such as 6-AB-40 or 4952
Such as feb-14-a3 or 236-80
All of them sensible everyday names
There are fancier names if you want them descriptive
Some may be helpful, or those are their aims
Such as crashes-on-pasting or name-too-restrictive
But all of them sensible everyday names
But I tell you, a bug has a name that's specific
A name that's preciser and more optimised
Or coders are lost in an ocean Pacific
If the testers can't make it well characterised
Of names of this kind I can give you a quorum
Such as "Paste aax while holding alt-P"
Such as "Use umlauts in a 300 post forum"
Names that never belong to more than one bug
But above and beyond there's still one name left over
And that is the name that is not safe for work
Except disembowelled, or rot-13 coded
The name it provokes from those who discover
The CUSTOMER KNOWS, but she cannot confess.
When you notice a user in deep meditation
The reason, I tell you, is always the same
His mind is engaged in outraged frustration
And suppressing, suppressing, suppressing the name
The vulgar, unprintable
Fscking deletable
True and ineffable singular name.

Autocorrect: scruffy.
That should have been 'disemvowelled', of course

And then there's the beginning user error:

The new auditor, given his laptop, and told he must format the floppies before he tries to record data on them...

What does he do when the C: prompt comes up?

He types one fatal word: FORMAT

The computer asks him if he really wants to do this...and he types "YES"

He spent the whole next day reloading all the software onto his laptop.

paul @44:

It's a scale, so all the major positions on the scale are described. It's like a thermometer, which doesn't necessarily imply that everything goes from boiling to freezing. Entropy implies that systems will move downward, but where they start and whether they resist that are human choices.

My job is to make sure that nothing worse than scruffy goes live. Sometimes something buggy gets in because business need makes us take the risk of putting that much tech debt live. But generally, if it's worse than scruffy (and I know it), I won't sign it off.

I signed off on something that went live this morning because I thought it was no worse than scruffy. It wasn't; it was brittle. So we rolled it back. I'll get stick for signing something off that wasn't good enough, but I'll get no trouble for pulling the plug. Because brittle isn't good enough for me. And I have my job because my company likes that I have that standard, as well as all the practical skills to make holding us to it possible.

The realistic lifecycle I expect from my systems is scruffy - (fix) - stable - (upgrade) - scruffy - (fix) - stable, ad infinitum. I would love to start out at stable, but I don't think it's realistic to expect it. And though I'll live with buggy - (fix) - scruffy - (fix) - stable, and even buggy - (fix) - scruffy forever, if it's brittle or fragile, the dev team is going to have to work hard to get anything but fixes past my signoff.

The last time I saw a clean system was in banking, and even there they're thin on the ground. But I can still hope for one. As Robert Browning said, ah, but a man's reach should exceed his grasp, or what's a heaven for?

Thomas @ 48 Yours is better.

I like both Sisule @43 and thomas @48. Fantastic! And thank you, Serge, for bringing that classic in. I have no idea where it's from, either.

I've heard Jordin Kate do that abort, retry, ignore poem in circle, he might have a source.

Abi and others, this paper about how complex systems fail might be useful: http://www.ctlab.org/documents/How%20Complex%20Systems%20Fail.pdf

At one place where I worked once, we did not say that software had bugs. We said it had issues.

Bronwyn @55: I love that paper. It expresses so much that's right. (Our users' workarounds, that we were talking about before -- that's item 12.)

At my work, we've been working with those ideas as expressed and elaborated in Engineering a Safer World, by Nancy Leveson (free PDF at the link). Prof. Leveson does a great deal of work with case-studies and research to build the case for a systems approach to safety, and then goes on to give a couple procedures to use to apply a systems approach to safety to the design of complex systems and the investigation of failures. We're currently working on an incident management procedure incorporating features of CAST.

It's the kind of book which is relatively easy to pick up incrementally -- the first few chapters provide a lot of the groundwork, and so you don't need to read the whole thing to start to apprehend the value it provides. (I found the worked example in chapter 4, the analysis of a friendly-fire incident, remarkably persuasive of the value of the ideas contained in the preceding three chapters. It might even make a reasonable place to start.)

Kellan, Bronwyn: another strong endorsement for Prof Leveson.

Some of my colleagues and I talked to her once about how the safety-engineering ideas could be applied to prescription-drug regulation. Very interesting.

Xopher and abi:

Aha. I was taking "Entropy tells us that, barring intervention, systems tend to move down this sequence" as a stronger statement about events than was intended. (And apparently also misreading "intervention" as "Intervention.")

I've thought that several of you might be coworkers, but rarely do all the details match.

I do mostly web based "cloud" software these days, where there's several types of memory abuse. One is the "asymptotic memory effect". Not a classic leak, the memory is all accounted for and released on program termination - except that the program is a Web service, and doesn’t usually terminate under normal circumstances.

In my Nortel days, there were terms like "store gobblers", "memory stompers", and the ever-popular "babbling idiot". A babbling idiot was a failed hardware device sending an unending stream of defective messages on the internal bus.

And then, there were IP broadcast storms. When those happened, with the workstation systems of the day, a very movie-like effect happened: the windowing system scrolled off the screen, and the line-mode console scrolled repetitive error messages for half an hour or more.

I don't think there's been a mention yet of Verity Stob's magnificent Windows Cruft scale which traces the gradual decay of a freshly installed Windows system. It's a similar and equally worthy progression to the one which started this post.

Please gnomes - be kind to this url:

http://www.doc.ic.ac.uk/~susan/475/cruft.html

Thanks to Sisuile and thomas: I liked both of the Namings of Bugs.

I've often seen complex bug priority/severity rankings rot over time. The more options there are for priority and severity the less likely it is that everyone will spend the time to make fine distinctions. This has been especially true when developers were among those doing the rankings.

With regard to system stability, as opposed to individual bugs, context can matter hugely, and occasionally surprisingly. A system can be apparently "stable", or at worst "scruffy", with one set of users and tasks, and then turn "buggy"/"brittle"/"fragile"/"fucked"/"returned with penalties according to contract" when an apparently similar set of users or tasks pushes just a slightly different set of buttons. (This also applies to components of systems, of course, as when "leaks very slowly but cleans up on shutdown" meets "long-running server".)

I am quite certain that all projects start at "clean".

And then the first programmer writes the first line of code...

Perhaps: and then the first design decision is made...

Reminds me of the Secure Computer, according to my Crypto Professor: "a computer that has never been plugged in, never been turned on, on its largest-area side, and used as a stepstool."

Mycroft: the version I've heard ended "...encased in concrete, and dumped in the Marianas Trench".

...in a locked room under a mountain, with two armed Marines at the door.

That's not secure. That's a self-inflicted denial of service attack.

TomB #66: Ooh, score! I've seen a lot of variations of that joke, but I don't think I've ever seen someone point that out.

The Jargon File also has a useful term for something between "brittle"/"fragile" and "fucked". See crawling horror.

abi, in your black box taxonomy, I would use 'crawling horror' to describe the kind of working and usable system that has a third quality in addition to being both generally unreliable and likely to fail catastrophically at any moment, namely that it is inscrutable to the people who have to operate or attend to the maintenance of the thing.

It falls over a lot. Then it starts working again, sometimes. Nobody knows why or how to control it.

When it shatters into a million pieces, there will be nobody who knows enough about what it really does to build an adequate replacement.

I was once acquainted with a multi-million dollar piece of ancient spacecraft manufacturing equipment that had these characteristics. The software written in Fortran 77 of course. (Hopefully, it's shattered by now.)

TomB @66: Touché.

dotless ı @62: This also applies to components of systems, of course, as when "leaks very slowly but cleans up on shutdown" meets "long-running server".

A lot of systems I've seen like this just schedule a preventative restart periodically, because scheduling the restart means you can stagger it, rather than getting a traffic spike that causes weird resonance behavior as big groups of nodes overflow their memory and trigger the kernel's out-of-memory killer. I've always felt vaguely unclean about it, and it is probably "scruffy" at least in Abi's taxonomy, but it does appear to work for slow memory leaks.

Addendum to my response to TomB @66: The shorthand we have for that at work is "Availability is a security goal."

I keep reading these, and thinking "brittle is an awesome category--it's the structural nature of banking."

Which leads to the interesting question of what a non-brittle banking system would look like? (Followed rapidly by, and how can we get there?)

From the user's perspective it can be hard to distinguish a scruffy system from one that's merely badly designed. Requires weird workarounds? Check. Occasionally has things happen for no apparent reason? Check. (I was just reading this relevant pointer to a dystopian time travel themed rant on Language Log.)

j h woodyatt@69: Does "crawling horror" belong on a separate axis? It seems that from a black-box perspective it's mostly distinguished by the difficulty of moving into a more stable state. From a white-box perspective it's another matter: it's a dark vortex of insanity that no one wants to enter (in part because there's always the risk that the next person to enter will become the new "expert" on the system).

Kellan Sparver@70: Conversely, scheduled restarts often come into existence for other reasons (say, because of a daily batch cycle) and hide resource leaking problems. Then someone has the bright idea to start handling another time zone or two, the batch window shrinks or disappears, and your nice stable software gains an insatiable appetite for brains resources.

I see that I've got one dystopian future, one Lovecraftian horror, and one zombie metaphor in this comment. Am I missing anything? Dinosaurs should fit neatly into some of the "crawling horror"-type system descriptions.

74
Don't the dinosaurs come in as legacy systems?

Abi: "Which leads to the interesting question of what a non-brittle banking system would look like?"

Unfortunately, I suspect the answer is "A system in which all banks agree on what services they provide, how they keep records, and what internal workflows they use for handling customers. And they never change any of those things."

"...Also, they're all in the same country and that country never changes its banking laws."

"...Also, a pony."

This is not to say that the current system could not be systematically improved. Of course it could. (He says confidently, having brushed past a tiny corner of the financial computer network in 1999.) But it got where it is through incremental evolution.

abi, #73: Well, we had one for 50-odd years; the recent instability in the system is not inherent to banking at all, but the direct result of lack of sufficient regulation (aka bug-prevention). We know how to do this, but at the moment we are choosing not to do so.

Banking is structurally a lot like the internet. It is a reliable ("stable") system built on semi-reliable ("brittle") protocols with eventual consistency.

(When your stable system is taken over by gangs of gamblers and thieves is another story.)

P J Evans @ 74: Don't the dinosaurs come in as legacy systems?
The sad truth is that all systems are legacy systems. Anyone who thinks they don't have embrassing "legacy" code either hasn't done their first deploy, or hasn't really looked for it.

Legacy adj. (software) mature, reliable. unfashionable.
(hardware) desperately needing spare parts.

Legacy System n. deprecated description meaning "it works".

dotless ı @74: My friend who at the time worked for a large five-nines Internet company was pretty disgusted at some site (maybe a federal student loan site?) which had a nightly outage between midnight and 6 AM Eastern to, I don't know, aerate and drain its database or something. "Boy it sure would be nice if my systems could take the night off."

Sometimes the answer is to make the system more distributed, but often that just leaves you with N problems (and N^2 interactions) where previously you only had one.

The banks don't particularly value technical work. They are run by finance guys; engineers are the help, a necessary evil to enable the "deal flow". This is particularly evident in the governance structures. Morgan Stanley, for instance, doesn't seem to have an engineer on their operating committee.

here

Not a CIO or a CTO in sight.

Kellan Sparver@81: I feel like I need to say a little in defense of systems with that sort of batch window, especially after my comment at #74. (I mean here a system that has x hours of online processing when it interacts with the outside world and y hours of batch processing when it's just chewing over everything it knows.) There are reasons for that kind of system design beyond "they didn't know how to write software in those days". Systems like that are much easier to reason about in at least two respects:

Correctness: especially in financial processing it's much easier to get a system correct, make it robust as it changes, and make it possible to back out mistakes, if you have a strict order in which everything gets done; and that's easiest to do if you can say "the set of data we're working on is what we have as of midnight Eastern Time."

Resource use: if you know that you have a certain set of hardware resources entirely for a certain step of a calculation then it's easier to make full use of those resources without overcommitting.

There are ways to deal with both of these issues in fully online systems, as you mention, but they add complexity, which adds opportunities for mistakes and inefficiency. Simplicity is a good starting place, as long as what you design actually fits your requirements. On the one hand, you can get in trouble when requirements change; on the other hand, you will get in trouble if you try to design a system for every possible requirement.

I have a lot of sympathy for people who designed banking systems to do their batch processing in a straightforward fashion when the branches were all closed; and also for those who were later told "we now have branches in every time zone, so make it work."

Cadbury Moose @ 80: Hear, hear! Legacy system is so often vendor-speak for "we can make money off you".

doubled letters, bad grammar (I guess "Do you've any?" is technically correct, but it's not in my ideolect), and commercial name and link. Looks spammy to me.

Buddha 85: I guess "Do you've any?" is technically correct, but it's not in my ideolect

In my dialect, and most of the American dialects I've heard, only linking and auxiliary verbs can be contracted. So I can say "I've gone," but not *"I've apples," and "I'm gonna go" but not *"I'm gonna the store."

I have heard Americans say things like "We've plenty of apples," but only when they've been reading lots of British novels.

Now, of course, someone will chime in and say they've always contracted 'have' no matter what it means, that everyone in their family does, and that none of them have never been anywhere near an English novel, an English person, or a British TV show.

Well, that would be new to me.

Xopher, #86: I'm with you; native English speakers don't use that formation in that context. I did once hear someone say, "I'm better at X than I'm at Y" -- but that person was not a native speaker of English, and I did politely mention, in the interest of helping them improve their English, that the second "I'm" should not have been a contraction.

I can imagine someone slurring "I'm going to the store" in such a way that it would come out sounding like "I'm gonna the store", but that's an issue of enunciation rather than usage.

I think substantive 'have' is contracted in British usage, but not "going to."

In fact, I first noticed the pattern when I crossed the street the "wrong" way in front of a school crossing guard (I was in the habit of greeting her each morning). She said "where are you going?" I replied "I'm going to vote." This meant I was physically going toward the polling place; had I just been announcing my intention of voting, I could have said "I'm gonna vote," but not in reference to the physical act.

In marketspeak, legacy means "our competitor's current offering".

Lee @ 87

"I'm goin' a store" is actually pretty common in my experience, (or even just "goin' a store," as in "Goin' a store; you wan'ything?"). I've always thought of it less as slurring than as shorthand, though I could be kidding myself as to whether there's any difference...

KayTei (90): Now I'm reminded that my sister and I eventually shortened our perpetual mutual question* "May I read one of your books?" down to "Myreedwannayrbks?"--a very rapid single word (with the syllable break before the 'd' rather than after).

*to which the answer was always "yes"

abi @ 73
All the below gets an "in my opinion."

It's impossible to build a non-brittle fractional reserve bank[1]. (Full-reserve banks are favorites of some portions of Occupy, some followers of Mises in economics, and some goldbugs; they seem to have costs greater than their benefits.)

The key thing to remember is TomB @ 78 ; you can build a not-very-brittle system out of brittle components; that's largely what we had in the 1940-1970 timeframe. After 1973, as the brittleness of the components became visible, a lot of efforts were made to make BANKS less risky; unfortunately, a large portion of the result was to make the banking SYSTEM more brittle--less banks failed, but when the system failed the whole thing broke.

Key features seem to me to be a reliable guarantee of some bank deposits--that means that individual banks are not too large, and the total of insured deposits is small relative to the guarantor's ability to pay. (So--you need the FDIC, but you also need your banking system to be small relative to the government's discretionary spending.) Also, a clear prohibition on making bank-like promises (maturity transformation) unless you are part of the regulated system.

The problem with a brittle system with idiot observers is blaming the operator when the system fails--"it worked fine for months, and then we hired Joe and it broke irrepairably" can be "Joe is incompetent" or it can be "the system was brittle"; if the problem is system brittleness, focusing on Joe's competence is counter-productive.

1) Basically, if deposits can be withdrawn but loans can't be called, you can't get away from bank runs as a possibility.

Xopher @86 and following.

Here in New Zealand, I might well say something like "I've apples," in response to a question, and I doubt it would be thought strange.

Not, I think, in other contexts.

"I'm gonna the shop," I would not say, but I don't normally say "gonna" in any context. That's just not a contraction I use.

J Homes.

Johan Larson @ 82: The banks don't particularly value technical work. They are run by finance guys; engineers are the help, a necessary evil to enable the "deal flow". This is particularly evident in the governance structures. Morgan Stanley, for instance, doesn't seem to have an engineer on their operating committee.

I'm not surprised! I had the misfortune to need to use Morgan Stanley's website last week, because my employer chose them to administer a stock grant. They were unable to email me my login information (the person on the phone was clicking something to send it out, but it never reached me, my junk folder, or my IT organization's spam filter in the Exchange server.)
They tried to talk me through it on the phone, but the website choked when I had to view a PDF. My call was escalated to a more technical support person. "I'm using Chrome on a Mac." "I see. Would you please use Internet Explorer?" That took about another hour, with no success.
I called the broker back. He couldn't do a trade over the phone for me until I activated my account online. I finally dug up a Windows VM and used IE. He apologizd profusely, and assured me that they are rewriting the whole thing, and it will be done at the end of the year.
I clearly will never choose to use them for my own account.

94
I love sites that make assumptions about what people are using. (Ancestry assumes you're using IE for uploading. It won't upload with FF. WTF, people?)

janetl@94: In fairness, making a website work smoothly on all browsers is hard. I'm on the server side, so I don't have to worry about this stuff, but the front-end guys are always swearing about subtle incompatibilities across the various browsers. Things mostly work the same on all of them, until they don't. Sic semper weak standards compliance.

It's possible to be conservative and use a safe subset that works reliably, but then you are pretty much working with the (thoroughly debugged) last generation's technology, and engineers are reluctant to do so.

So it's not very surprising that you ran into problems using a website with an unusual OS/browser combo. Unfortunate, though.

But who uses IE anymore? Don't most users use FF or Chrome?

97>

The population of users using IE has been falling rapidly, but it's still high enough that it needs to be considered. It's especially problematic for sites that are expected to be used from work environments (like benefits sites, which is where I've had the most trouble), since employees are often not allowed to install or use different browsers and some clients will demand that IE be supported. It was a happy, happy day in the office when we were able to stop supporting IE8. (I'm way on the back end, I don't care about this stuff, but the front-end guys were over the moon.)

I think people assume other people use what they use. "But who uses Chrome? Firefox, maybe, but everyone uses Internet Explorer," makes just as much sense to me coming from someone who uses it. It doesn't mean it's not frustrating-- a couple years ago, I went in circles applying for a job where the survey portion required Internet Explorer but didn't say so anywhere-- but IE comes on Windows computers. For a great many people, there's no reason to change. It's easier to make small adjustments as they're needed than to make the big adjustment that might avoid them, but only might, and it means that the subsequent issues are your fault for changing things.

I do the same thing with music players. I still use Windows Media Player, though I was told nearly a decade ago that no one uses it and it's no good-- but I don't notice its problems and everything else has the problem that I don't have it and it requires effort to change.

We have a mission-critical application which requires IE. Yes, that's a contradiction in terms. I've got it in my mind to kill, if I can.

I can pick and choose at home, and use Chrome or Firefox for that reason. At work, where I have no control other the matter--it's IE.

I recently spent 50 hours data-entrying hundreds of customer inquiries and sales for a used equipment dealer. Two of the fields were "browser" and "OS". I got so I could type IE <tab> Windows in my sleep. I just pulled up the spreadsheet, and here's what I've got:

0.2% used Avant for Windows,
0.2% used Safari for Linux,
0.2% used Safari for Windows,
0.4% used Opera for Windows,
0.6% used Firefox for Mac,
0.6% used Google Chrome for Mac,
2.0% used Safari for Mac,
4.2% used "other",
8.2% used Firefox for Windows,
10.1% used Google Chrome for Windows,
73.6% used IE for Windows

Yes, that adds up to 100.3. There was more rounding up than rounding down. The rounding error was larger than the percentage of people using, say, Safari for Linux in this sample. And over 90% of businesses who inquired about buying things used one of three browsers: Firefox, Chrome, or IE for Windows. If I ever tried to buy a piece of equipment from them I'd be a whole new entry: Firefox for Linux.

There's a Safari for Linux?

Last night I went to use a website that asked me to download a recent version of Chrome, FF, Safari, or IE, as my browser wasn't supported. My browser was the dev version of Chrome. Apparently, what they really wanted me to do was use something other than Linux, but were unclear on how to communicate that. I suppose my browser asking about allowing Silverlight on that page should have been a clue.

Apparently so, though I'd certainly never heard of Safari for Linux before, either. I do wonder what those "other" browsers and OSs might have been.

Where I worked they used IE (it was IE7 when I left). I put Chrome on it as my backup browser (because I didn't have an updated version of Flash and was using google streetview for a lot of stuff.)

Xopher Halftongue @97: But who uses IE anymore?

It's our enterprise-standard browser. Worse, we just got upgraded to IE8.

The latest Java update has borked my employer's VPN software on four of the five browsers I work with: Chrome, Firefox, Safari, Opera. Since it was clearly a security problem, I fell back to the insecure browser, and indeed, IE worked just fine.

(Why do I have five browsers? Do you really need to ask?)

You test web-based software? Gotta have all the most popular browsers.

106
We got IE7 and Office 2007 in 2011. They were still testing IE8 for software compatibility for the department I was in.

I don't test it any more. But I have tested it, and old habits die hard.

OK, I confess. I'm a browser hoarder. It's like collecting color-blind people after having done accessibility testing. Not that, um, I would know anything about that.

abi @ #110

That's what they all say. Once you've got a couple of test cases you must collect the set.

(This moose just sticks with Safari.)

abi: Well, you never know when you might need one.

We've been wrestling with IE 11. In an interesting attempt to persuade people like me to use feature detection rather than browser detection, it doesn’t have IE in the user agent string. It was initially logged as Mozilla 11. It’s moving up the standings fast, but we're forcing IE 10 compatibility, and even there, having to revisit some things.

One of my bêtes noirs is that various browser versions choke on comments in css (cascading style sheets)! This might have an overlap with some of the browser specific hacks used in our third party commercial framework to get consistent rendering.

Re: grammar, some rapper recently popularized "I'ma ...", apparently representing "I'm going to ..." in the action sense. Apparently it was originally a regionalism.

My late father-in-law knew a guy who got to do photo interp for the military during WWII by accident. I don't remember the backstory as to why he was in the same room with the photos, but he looked at them and asked, "why is that tank there?" Much consternation ensued because no one else had seen the well-camouflaged tank.

The trick with collecting color-blind people is finding ones who are comfortable admitting it. Not everyone is.

There are ways to guess, particularly if one gets to see their wardrobe over the long term. There are particular shades of red and green (particularly a kind of grey sage-green) that are indicative. I've never "outed" a color-blind colleague—that would be incredibly rude.

But I've had the good fortune to work with some very open (and in one case, genuinely flamboyant) color-blind people, who have made accessibility testing so much easier for me over time.

Henry Troup @113:
One of my bêtes noirs is that various browser versions choke on comments in css (cascading style sheets)! This might have an overlap with some of the browser specific hacks used in our third party commercial framework to get consistent rendering.

Whoa. Tell me more, if you can?

There are particular shades of red and green (particularly a kind of grey sage-green) that are indicative.

Hey, I have pants like that, and perfectly good color vision! I just like green, and that's the only green a guy can get away with pantswise. ;-)

I shall out myself then: I have a very rare color deficiency -- it's the blue receptor -- so I have trouble with blues vs greens (mainly at a distance, but my father sees only shades of gray), and reds vs oranges, in particular pink v orange. It's just not possible for me to distinguish pink and orange as separate colors, only as relative intensities.

I don't care for reds and greens (as fonts and backgrounds), but I can read them. Yellows, however, disappear.

My mother has particularly good color vision (possibly in her optical hardware; possibly related to her 'trick memory'). She can see you in a given sweater in March under fluorescent light, see a coordinating scarf under incandescent light in August, buy it, and mail it to you, and the two items will go together as if matched in person by a skilled stylist.

That said, she found an interesting fillip in it: while she was gestating me, she crocheted a bunch of afghans (as one does, especially in the 70s). After the birth she suddenly realized all the multicolored things she'd done during the last 5mo of gestation were, um ... very loud to her non-pregnant color sense. While she was making them they looked perfectly reasonable and cheerful, and afterwards? Something between acid-trip and horrible-golfer-pants. She gave away the ones she could no longer quite stand to look at, but I have the remainder. :->

I wish I had that kind of color memory, Elliott. Very useful for a fiber artist. :) It's also possible your mother is a tetrachromat; the evidence for the trait existing in humans is small, but there. It would help because she'd be seeing more distinctions, I'd imagine.

My father's red-green colorblind, which means I'm a carrier, though my color vision is normal. He can distinguish red and green with effort, he says, but does so mostly by value rather than hue. He's also pretty bad at telling the difference between brown and grey, which led to an amusing incident when he wanted a brown suit. He had one tried on that he liked, and when the clerk went in the back to check something I said, "I thought you wanted brown?" Because the one he'd been trying was grey. I dunno whether the clerk was trying to sell him the wrong thing or was colorblind himself and had made an honest mistake.

Lo these many years ago, when I was a freshman in college, I hung out with some of the people from the campus radio station. Their engineer, a senior, was colorblind. If he needed something done that relied on color vision, he'd grab the nearest warm body.

Ginger: I'm pretty sure I've got a milder form of that; I've never once tested as colorblind on any official test, but I can't see the Wikipedia tritanopia test (found HERE) while my husband can, on two different computer monitors, and my twin sister can't see it either, while her husband can. I know that computer screens aren't reliable, but the fact that they can see it while we can't, on the very same screens, is suggestive. I also have problems with the orange and pink triangles and the blue and green triangles in Trivial Pursuit unless under really good light.

Tritanopia is the name for the full yellow/blue colorblindness, while tritanomaly is for impaired yellow/blue vision. I'm pretty sure that I've got tritanomaly: either I have fewer than normal yellow/blue cones, or their frequency response is off-spec.

I suspect one reason that tritanomaly and tritanopia is so "rare" (0.01% of the population) is because they don't test well for it.

Our main DM back in the day was red-green colorblind. He coded his wilderness maps by shade, but used red and green pencil interchangeably. Never needed a screen.

My husband is partially red-green colorblind. He can distinguish bright shades, e.g. Christmas tree red and green, but he can't tell the difference between a hunter green and a deep maroon, or sage green and gray.

I knew that, but until our first daughter was born (after 14 years of marriage) I hadn't realized that he couldn't tell pale pink from white. Then he began matching - or not matching - her socks. All those years I thought he was remarkably laid back about undershirts turned pink in the wash, since he never complained, no matter which of us was the culprit. Turns out he couldn't see the difference. :-)

Cally, #122: Of the 3 color tests on that page, I can see the first one pretty clearly, the second one more-or-less (as in, I can see something, but I can only tell you what it is because the caption tells me what it is), and the third one not at all.

Since I have never had any reason to think I have a color deficiency, I went looking for other tests online, and found this one -- on which I answered 31 of 31 questions correctly, for a suggested 0% color deficiency in all categories.

I don't know why you, your sister, and your husbands are getting the results you're getting, but I would wonder at this point if the problem is in the Wikipedia test rather than in your eyes.

Cool test, Lee @125. Much easier to see the figures than on the Wikipedia test.

@#51: Abi, I've made exactly ONE clean piece of software. It's for the TI-83/84/(plus versions) family of graphing calculators, and its simplicity is really the only reason it is clean to begin with. The code is as follows, replacing "sqrt" with the actual radical symbol:

: Prompt A
: Prompt B
: Prompt C
: Disp "X=",(-B + sqrt( B^2 - 4AC))/(2A),(-B - sqrt( B^2 - 4AC))/(2A)

I use it in algebra class, to grade student papers more quickly.

For really short programs like that, cleanness is basically like the A on the test. You've debugged frequently, and the code is short enough to read through every line within an hour checking for typos. Hence, all the bugs are both findable and fixable in little time. Doing everything right in the programming and debugging phases can get you the A+ that is a clean program. At worst, you're looking at a stable program, which is still really good.

Once code goes beyond 100 lines or so in length, clean is less like an A on a test and more like the Holy Grail; you can try as you might, but you're extremely unlikely to find it.

As for myself, I gave up on programming after my second course in C++. It wasn't that I was a terrible programmer; I just had the particularly ill luck to take the second course a year after the first, with next-to-no programming experience in between, and sold my intro book. (I was under the false assumption that there would be a "cheat sheet" of basic symbols inside the cover. I think I assumed that because of those handy "List Of Common Integrals" tables inside the cover of every calculus book.)

I've just been smiling and nodding at the explanations, as an end-luser who knows this stuff from personal experience, mostly of the type that resulted in my father screaming "Damnit, she crashed the computer again?" Frequent offenses were saving really huge BMP files (in the mid-90s when harddrives were teeny) and playing around in Windows Explorer once I discovered you could open a video game's sound effects that way.

127
Your calculus book had a cheat-sheet on the inside cover? Lucky you!

The_L @127:

Ah, see, as an ex-mainframe jockey, I know better than to presume that shortness and simplicity mean cleanliness. I've worked with IEFBR14, the one-line program written to do nothing*, which had a bug. Solving the bug tripled its length and introduced two more bugs.

Because computers and unintended consequences go together like forks and toasters: inevitably, eventually, but with sparks.

-----
* Doing nothing is useful sometimes. It's not so much Zen as z/OS

abi @129 Solving the bug tripled its length and introduced two more bugs.

At some point in my programming days (which were long ago and on systems lost to the mists of time), I encountered the word iatrogenic and gleefully clasped it to my heart. The term is medical, descriptive of an illness inadvertently caused by a doctor. Way too many of my bugs were inadvertently caused by fixes to previous problems.

One of my high school's best artists was colorblind. But he had the best color sense-- he just couldn't tell except by position which colors were which. He produced a bunch of interesting still lifes.

IEFBR14, Abi? Wow. That takes me back a decade or more.

So it was the OS/360 equivalent of /bin/true on modern *nix?

Oh, my - IEFBR14....

Next we'll get a S0C7 because we plugged a character into a COMP-3 field. :)

Stop me before I start missing COBOL.

I'm fond of unf***yourhabitat.tumblr.com/ (housekeeping with much swearing). I wish there were an Unf*!@YourCodebase equivalent. I don't think the challenges would be only 20 minutes long, though...

Abi @#116

The hack in question is style="border/*\**/:solid 1px #bebebe\9;background:#fff;"
I think this either hides something from IE9 or the reverse, as I said it gets injected partly in 3rd party stuff.

That should be a validly closed comment regardless. But I made an Ajax error in the Chrome browser go away by stripping all comments that were inside styles (except for these hacks).

Fragile, version and browser specific, ugly as sin, and regrettably necessary.

I had to rewrite IEFBR14 once. It took two tries, which is *embarrassing *, as it should be two instructions. I recall
SR 15,15
BR 14

My mainframes were VM/CMS starting with 3033 machines. One generation was water-chilled, requiring an on-call plumber. One winter we had a computer freeze - an operator had to take a blowtorch to the chiller, with his feet at -30 or so.

As I understand it, IEFBR14 is a great example of (one reason) why systems are hard: doing nothing is easy, but doing nothing in a way that interacts correctly with everything in the system is harder. (There are a few slightly conflicting histories of IEFBR14 floating around, but the first of these starts with a program that does nothing and then gradually turns it into a program that does nothing, returns a successful result, and satisfies a bunch of other conventions.)

Lee @ 125 I got 40% tritanopia on that test. I don't think it's just Wikipedia....

Cally Soukup @ 139, I only got 25% tritanopia. (Everything else was zero.)

My father was colorblind (R/G, partial), as were his brothers. As usual, I'm free of it¹ He had my stepmother disambiguate his blue and brown suits, but was not happy about the new international standard for buoys at sea. (The old US standard used red and black, the new uses red and green.) One of my uncles pointed out the flip side: "That used-car salesman says it's never been in an accident, I can point right to they painted it."²

Naturally both my sisters are carriers, and one of my nephews has trouble with red versus orange.

¹ Instead I've got "Grandpa's eyes", the enhanced color vision from Mom's side of the family.

² After hammering out the dent; this was before composite body panels. R/G colorblindness gives enhanced detail vision in proportion to the degree. I don't know if that applies to Y/B colorblindness.

The guy who led most of the camping trips my parents went on was a birdwatcher. And completely colorblind.
He was pretty good at identifying them, though.

PJ Evans: I bet being colorblind would actually help with identifying the LBJs*, as well as initially spotting them in a busy woodland environment.

* Little Brown Jobbies. Sparrows and the like. There are lots of them.

1443
Yeah, you'd probably miss most of the leaf-birds. (Birds that look like leaves - or pretend to be leaves. How the heck an adult male oriole can hide in a half-leafed-out tree is something I don't understand.)

Elliott @ 119: Fascinating! Changes in smell/taste during pregnancy are almost a cliché (cf a bit in a recent Sherlock); I'd never heard of vision changes, but the visual system is so complicated that assuming it never changes under shuffled hormones seems rash.

Lee @ 125: Thank you. I also found 2/3 of the Wikipedia examples impenetrable (a bit disturbing because I had to take the FAA medical exam before pilot training and got everything including the trick nothing-really-there test) and was pleased to get 31/31 on the more extensive test.

abi @ 129: I didn't do any real coding until the mini age, but I've heard tales of mainframe programs which depended on timing (e.g., of a drum memory) so I'm not surprised that a do-nothing program is useful.

re 145 et al: Most of those "test" on Wikipedia are things some user just made up, so I wouldn't take them seriously.

CHip@145: Do-nothing programs are useful even in more recent environments, depending on how you assemble programs together. /bin/true on UNIX is another example.

My understanding of a (the?) main use for IEFBR14 isn't about timing. It's that in JCL, which is used to script batch jobs, a step consists of a program to execute, along with potentially very detailed instructions about what to do with the resulting datasets in the event of success or failure. If all you want to do in a step is to manage datasets then it's useful to have the lowest-cost successfully-exiting do-nothing program to execute. (I don't have the z/OS background of abi or others here—I came to z/OS late, tangentially, and from a weird direction—and I'll happily take any corrections to my understanding.)

Well, /bin/true isn't exactly a do-NOTHING. It does one thing (return the status code that signifies success) extremely reliably.

Dotless I and Matthew, you're both correct. IEFBR14 succeeds at doing nothing, as does /bin/true. Both exist to fill the need for something to be executed, when there's nothing that you actually want that isn't accomplished as an effect elsewhere in the processing. JCL could, for example, do a data set copy, but the stricter required an execution step - so, IEFBR14.

The original /bin/true was an empty file, the only perfect software I know of. But then people want help in all programs, and so on, and it got bigger and wasn't perfect anymore. Maybe /dev/true would have been a better thought.

Abi@107, guessing why you have five browsers? It's because you've decided that testing on Lynx isn't really necessary any more :-) And you probably also test on Firefox with NoScript turned on as well as off, and other variations on Doing The Right Thing.

I get frustrated with the couple of systems I encounter that refuse to work with IE8; look, we just recently got the $DAYJOB HR department to get rid of the IE6-dependent applications, which let the Desktop IT department move up to something a bit newer, and I also use IE8 when web pages don't work on Firefox. But I'm one of those It Should Work On AnyBrowser types (why, yes, my hair is gray, why do you ask?)

On colorblindness, Dan Kaminsky (mainly known as a network security expert) has an augmented reality application for iPhone and maybe other things by now (webpage) that maps colors into other color spaces so people with various different types of colorblindness can see them using the colors they are able to differentiate, and can also get feedback on what colors specific things are. (He charges $3 for it, and I don't have an iPhone, or color blindness, so I haven't tested it, though it sounds like he's also come out with an Android version since then, and there are apparently similar accessibility apps that run on PCs.)

Somebody's commented on the birdwatcher who was colorblind but good at identifying birds; there's been a general comment that colorblindness has some evolutionary usefulness in finding animals that are camouflaged against other animals that have normal color vision, so having some percentage of your hunter/gatherer group that can see the predator or dinner is useful even if they can't always identify the good vs. bad berries.

We got an ungood surprise with a software deployment today: a legacy web application has become substantially degraded in all current browsers. The previous version worked in IE 11 in compatability mode, or at least was believed to. After today, no creation of a particular object type.

Tomorrow, I will warm up a backup image and see if we were deluded before.

The silver lining is that the project to move to one UI has gained some urgency and visibility.

@abi, #129: I think maybe my perfectionism ("There can be NO BUGS in my programs! Ever!!") was part of why I didn't make a good programmer. The perfect is the enemy of the good, and all that. I also preferred super-simple programs, because I could see at a glance what everything did.

spam at 154

unfamiliar alphabet, definitely spam

Compliment spam @156