Textarcana

Coming back from a long hiatus to post this.

LOL I am the author and I didn't know what that comment meant when I saw it above!! Derp and I will go fix my broken links now :) Thanks for the heads up!

This is a good idea.

The fact you thought about it enough to write 3 paragraphs about it shows the stickiness of my click-bait technique. You may not like my post but you will remember it.

Yep. I spend a lot of time qualifying and hedging on these ideas in the work I do for software organizations. These blog posts are my opportunity to just lay my true opinions out for people and see what happens :)

While I appreciate the spirit of what you are saying, the average time on page of 3 minutes 45 seconds (across 2k uniques) indicates most visitors are continuing past the paragraph you claim would be problematic.

That's where I was going when I wrote this post. Logging and log analysis is a large part of the continuous delivery tooling that I've been working on for the past 7 years.

Weird it just worked fine for me. http://infiniteundo.com/archive/filter-by/text

Hey you saved everyone a click!

I am the author of the post and I approve this summary :)

Yeah, way ahead of you on that one. http://infiniteundo.com/post/87172935713/first-rule-of-hacke...

Vernor Vinge and Charles Stross spring immediately to mind. Also James Tiptree, Jr. was a CIA analyst in the 50s and 60s so probably was a regular user of the early government mainframe systems.

Yes, I write intentionally click-baity blog posts. You got me.

"who created it" implies a causal chain of events whereby someone is responsible for the bug. This is Safety-I thinking. John Allspaw addresses this when he states that "there is no root cause" for an incident or bug. So in a very practical sense YES the bug is "born" at the moment the user "discovers" it. Note that "discovery" here is in the imperial sense where the the user has drawn a line on the software map (so to speak) an labeled it: beyond this here be bugs. Devops very directly implies skepticism for causality as a primary/default phenomenology for understanding bugs.

> discovery does not bring about its existence.

I would argue that it does but this is a matter for phenomenologists. The practical result is that it's as if the bug never existed. Beyond that let's agree to disagree.

#93 No hard data. How would you even begin to measure such a thing? No two software shops are the same, hell no two projects within the same team are anywhere similar. How to baseline? What about the impossibility of a control group for a software team?

I find it interesting that a power log distribution would result in the kind of behavior I am describing: relatively small impact for even fairly large variations in the number of tests applied to a project.

Ok. I was just extrapolating out that if from a microsecond to a half hour 10^9 which is within a couple of orders of magnitude of the age of the universe in seconds, then from a microsecond to a year would result in a ratio that when expressed as an integer is much larger than the age of the universe.

I'm realizing as I type this that I am not totally clear here and I will do some reflection now as to how to rewrite this point so it does not raise such objections. Thank you again for your help with this.

But I am talking about scale. The number of different size "bricks" or "units" of time that you can choose in which to execute concurrent or dependent logic is staggering. And all too often this is overlooked. Thus "February 29 bugs" and "New Years Day" bugs, not to mention the entire error classes of race conditions and cascading failures.

#84 I am basing on Dijkstra's statement here that "from a microsecond to a half an hour of computing time confronts us… with the ratio of 10^9"

See here: http://infiniteundo.com/post/117192619718

"Time grain" seems like the wrong word here I will replace it with something more specific. Thank you for pointing this out and if you still dispute my math I would consider it helpful to hear why :)

Wow. Thanks for the detailed response. I will try to answer point by point.

#2 that tight coupling can ever be good comes as a shock to the learner

#3 any breakage is an opportunity learn from and about failure — also when it's broken and you know that is better than if it's broken and you don't know

Regarding regression testing: writing tests is a design activity so if it is "driven" by whatever happened to break last, that sounds like treating the symptom not the underlying cause. That is why I have never been a fan of "bug-driven development" nor of large-scale regression testing.

#20 "who draws the lines" is an incredibly important political question. So who makes the declaration that the so-called black box can not or is not to be opened? This was my point. I understand what a black box means in software testing parlance.

#31 check out this great article then: https://blogs.msdn.microsoft.com/larryosterman/2004/03/30/on...

#51 testing is runnable documentation and sufficiently advanced monitoring, particularly ubiquitous StatsD usage, is indistinguishable in practice from testing, see https://www.youtube.com/watch?v=uSo8i1N18oc

#66 I truly do not understand the objection you are making here. If an event goes unobserved and is without impact it is the same as if the event never occurred.

#83 no bugs always cluster at the interfaces between components

#84 Uh oh. I need to check my math and will respond further in another comment once I do so. Thanks!

#93 It's not that testing doesn't help. It's that if you have X amount of testing and you add Y amount of additional testing, THAT is not correlated with better quality. Likewise if for Reasons you do less testing in the future than you do right now, that is not guaranteed to degrade your quality.

I am the author of this post! If you notice inaccuracies or have thoughts, please comment here. I will be reading and responding to all comments as always.

On OSX it works for me using the default terminal. But in iTerm it didn't display properly :(