Brian Marick
Contacting Brian Marick
Federation handle:
@marick@mstdn.social
Brian Marick's Information
Brian Marick's Bio
Long-time software person (programming and testing). Involved in Agile from relatively early on. One of those grumpy old-timers who think it's lost its way.
I retired during Covid. I am now focused on https://podcast.oddly-influenced.dev, "a podcast for people who want to apply ideas from *outside* software *to* software."
There’s a podcast-specific account at http://social.oddly-influenced.dev. This, my main account, is for other tech tweets, boosts of the amusing or interesting, and some leftish #uspol.
Brian Marick's Posts
Brian Marick has 7 posts.
Brian Marick
In response to this post@samir One is "bring me the results of work you have done on my behalf." The other is "you're bringing me work for me to do."
Likes: 0
Replies: 0
Boosts: 0
Brian Marick
In response to this post@samir "Don't bring me problems, bring me solutions" is a horrible slogan, way too popular.
@marick And so obviously terrible! I wonder how it survives.
by samir, hibernating ;
Likes: 0
Replies: 1
Boosts: 0
Brian Marick
In response to this post...
Later, a crash bug was reported from the field. It turns out its fix also fixed my bug. (So, if my report had led to a fix rather than a dressing-down, a customer would have been spared that crash – we had many fewer customers than a typical OS today, so crashes mattered more.)
@marick Seems like a classic case of “we don’t pay all these people all this money to give us bad news!”
I am sorry to report that it’s still going strong.
by samir, hibernating ;
Likes: 0
Replies: 1
Boosts: 0
Brian Marick
In response to this post...
In one configuration, what I "churned" was the mount/umount system calls (used to attach new disks to the system). I discovered a race where badly-timed sequences of mounts in a short time would crash the system.
Tempers were somewhat frayed by that time in the project, as I recall, and I got dressed down by what we'd today call the CTO for filing stupid bugs: no actual user would ever have that pattern of behavior.
...
...
Later, a crash bug was reported from the field. It turns out its fix also fixed my bug. (So, if my report had led to a fix rather than a dressing-down, a customer would have been spared that crash – we had many fewer customers than a typical OS today, so crashes mattered more.)
by Brian Marick ;
Likes: 0
Replies: 1
Boosts: 0
Brian Marick
In response to this postI once helped test one of the early true multiprocessor Unix kernels (more than one processor could be running kernel code at the same time). My contribution was a program called `churn` that was easily tweaked to hammer on particular system calls with many processors at the same time. It was great fun! Only one configuration failed to crash the system. (It was also a fun use of code coverage*.)
...
...
In one configuration, what I "churned" was the mount/umount system calls (used to attach new disks to the system). I discovered a race where badly-timed sequences of mounts in a short time would crash the system.
Tempers were somewhat frayed by that time in the project, as I recall, and I got dressed down by what we'd today call the CTO for filing stupid bugs: no actual user would ever have that pattern of behavior.
...
by Brian Marick ;
Likes: 0
Replies: 1
Boosts: 0
Brian Marick
In response to this postOld fogie anecdote time!
I was once told that there was a known spacecraft-destroying bug in the Space Shuttle software. It would happen if the pilot pushed the wrong button during ascent. They chose not to (attempt to) fix it. A known bug that could be avoided by telling a highly-trained pilot "see that button? don't push it until you're in orbit" was seen as less risky than changing the code.
(1/2)
I once helped test one of the early true multiprocessor Unix kernels (more than one processor could be running kernel code at the same time). My contribution was a program called `churn` that was easily tweaked to hammer on particular system calls with many processors at the same time. It was great fun! Only one configuration failed to crash the system. (It was also a fun use of code coverage*.)
...
by Brian Marick ;
Likes: 0
Replies: 1
Boosts: 0
Brian Marick
I've been out of "black box" software testing for a long time. It used to be a problem that bug reports from testers would be closed for reasons like “no one will ever do that."
That is, the argument was that, yes, this result would be bad, but no one (or an insignificant number of people) would ever see it.
Is that still a problem?
Old fogie anecdote time!
I was once told that there was a known spacecraft-destroying bug in the Space Shuttle software. It would happen if the pilot pushed the wrong button during ascent. They chose not to (attempt to) fix it. A known bug that could be avoided by telling a highly-trained pilot "see that button? don't push it until you're in orbit" was seen as less risky than changing the code.
(1/2)
by Brian Marick ;
Likes: 0
Replies: 1
Boosts: 0