let's define blurgs. a 'blurg' is an event where a programmer understanding of "what my code does" is not "what my code does".
blurgs are an everyday part of programming, of course. we are more often "interim" than at a sign-off point. but i mean to restrict for this conversation the idea of a blurg to being a programmer-program disconnect that occurs *at* a sign-off point.
(a sign-off point is different for different teams. most of the folks i work with regard a source code push into the repo as a sign-off. others say the real sign-off points are only the days we go live. some orgs use many layers of sign-off to make it hard to sign off. whatever.)
at its simplest, imagine me saying, "when it runs it prints 3," but when we run it it actually prints 4. that's a pretty bog-standard blurg.
how important are sign-off point blurgs in the grand scheme of things?
years ago, stephen gould remarked that the "Age Of X" trope for periods of evolutionary history, like "Age Of Mammals", "Age Of Dinosaurs", was basically just silly.
it is now and always has been the age of bacteria. there is no measure for which this is not true. more individuals, more species, more range, more survivability, more biomass, the list goes on and on.
it is my contention that we are now and always have been living in the Age Of Blurgs.
it's not the age of procedures, or of objects, or of immutability, or of functionals. it's the age of blurgs.
there are lots of great fail stories in computer science. i have two myself that i find -- at a distance of a few years -- hilarious. fail stories tell us about lots of brilliant ways we can lose in the software for money game.
you can fail by not talking to customers. you can fail by getting entangled with your org's Software Prevention Team. you can fail by not considering that the internet is sometimes offline.
you can fail by not considering transactions per second, or by never trying your facial recognition software on people who aren't white. you can even fail intentionally -- i have seen that.
but, in my view, the overwhelming majority of failures in software for money come from just this one thing: a sign-off point blurg.
and when i say overwhelming i really mean overwhelming. yes, integration problems happen, or we misunderstand the requirement, or "they" misunderstand the market.
take the security flaws headlines. many recent exemplars involve extraordinarily complex analysis of things like pipelining or kernel mode. it's rather brilliant, actually.
but the lowly buffer overrun, and there are no buffer overruns that aren't blurgs, still exposes millions of devices every day to rootkits and worms.
imagine you shipped a buffer overrun. i have, one of my two great failure stories is just that: a 1K buffer should have been 2K, and the app wiped the user's drive every 1024 uses. for eight weeks. it was in the field for eight weeks. thirty years later i still wince a little.
purest blurg. had you asked me "what my code does", i can assure you that i would never in a million years have answered, "it wipes the hard drive every 1024 runs". never.
one description i've offered of this movement is that we've spent 20 years expanding our focus to include not just the made, but also the making, and that we are now expanding that again to also include the makers.
how, then, expanding our vision to include the makers and the making, should knowing that we live in the Age Of Blurgs shape our behavior?
i strive to answer this question in a bunch of ways in a bunch of different places. today, tho, i just want you to consider the question:
what does living in the Age of Blurgs *mean* to us, to how and what we teach and learn and actually do in the trade?
what does living in the Age of Blurgs *mean* to us, to how and what we teach and learn and actually do in the trade?
Here's a blog for easier caviling: "The Age Of Blurgs" geepawhill.org/the-age-of-blu…
