Bug Blindness

We should distinguish between skeuomorphic interaction design and skeuomorphic iconography. Attempts at skeuomorphic interaction design did fail badly, I'll give you that. Document readers that expect you to turn the page by pulling at the edge of the page, mimicking a page turn in a physical book, they're terrible.

But skeuomorphic iconography works: The more detail you add to an icon, the easier it is to form mental associations with what it does - and that goes even if you don't know the original object that it's based on. Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.

It feels like too much of the benefit from it has been optimising, rushing new features/markets, tripping over ourselves with new processes, vibe coding things just for ourselves. When maybe it could actually make things better for most people using software in their daily lives.

Hahaha. Yup. That's me :) Not the screensaver in my case. I leave my desktop "suspended to memory" overnight, and when I come back in the morning / afternoon, to wake it up I press the Shift key.

But, more on the subject, I kinda find it disappointing that the post doesn't try harder to analyze why this happens to the developers. The explanation doesn't feel satisfactory to me.

This was my experience working on a product that was virtually universally believed by its programmers to be of good if not excellent quality, while, in reality it was atrocious. Just to give you a taste of the quality: Jenkins landing page didn't work because it would take too long for it to load and various timeouts that happen when it fails to load would kick in and just mess it up so much it wouldn't have been useful anyways. Jenkins tests were generated from some horror-show templates written in YAML (some RHEL tool, forgot what it's called) and because there was no other way to test what the template generated other than to deploy the new test into the actual Jenkins server, the server was full of dysfunctional "orphan" (no longer tied to any template) tests that were never deleted. The only way to navigate to the test results of the job you were interested in where to memorize the way the templated name would expand into the URI components of the Jenkins job URL, have some other test results bookmarked, and then modify the URL of the bookmarked page to get the URL of the job you want.

The CI/CD team, however, decided to combat this situation by developing their own server which collected data from Jenkins and displayed a table with the most recent results for select jobs. Green and red being used to indicate whether the job succeeds or fails, the table was mostly red most of the time, with some jobs being continuously red for many months.

Initially, I was hired into CI/CD team, but when I remarked on the desperate state of events in CI/CD department... they wanted me fired, but the company was going through acquisition and they wanted a higher headcount, so, they kept me, but transferred into the least relevant department where I would be as useless as possible: the quality control!

My life as SDET (because QA is a curse word nowadays) exposed me plenty to the situation described by the author. The aspects that the author didn't touch on is that programmers working on such a product that I've experienced a lot are:

* Unwillingness to accept that a large proportions of the product is bad. People have this intuition that some parts might be bad. After all, that's why QA exists: they find a few things, things get fixed, and everyone moves on. And this is how it works in passable quality products. But the situation when everything is on fire and is going to hell in due course sounds alarmist to the people who are on fire and are going to hell in due course. After a certain amount of complaints, all further complaints are dismissed.

* Unwillingness to accept the existence of strategic mistakes. The QA simply is not allowed to voice their opinion on product or feature design. The only way a tester can initiate a fix is if they can create a test that illustrates the problem. Saying, for example, that "our error reporting is bad because it's useless to the customer and it cannot be meaningfully reported back to the developers" was dismissed as "nothing to do here" (but, actually, meaning: it's above your paygrade).

I don't believe either of these would've been fixed by "simply pointing out the bug", as the author claims. Our industry came to a particular way of doing things that are pathologically bad. The way QA works is OK-ish, when the product itself is of an OK-ish quality. When the product is really bad, the QA is powerless to initiate a fix. QA isn't trusted enough, and, usually, is perceived as a liability, and furthermore, stuffed with engineers nobody else wants. Unless this is changed, the pathologically bad products (like the Blackboard) will have no hope of ever improving (eventually, they will just die either under their own weight, or replaced by something else).

I use Firefox reader, but the same idea. I actually prefer it this way (except I don't like that the reader doesn't support Vi/Emacs navigation...)

For content that is just text, I prefer that the author keeps the styling to the minimum. It makes it easier to do it the way I want it client-side.