Dadhacker

I like to play a game sometimes, it goes like this: Take a current hot and screwed-up software methodology and try to project what its replacement is going to be.

For instance, the shiny bits of Scrum are starting to wear off like the cheap paint from a fake idol, but there’s still time to dust off the crystal ball and toss some coins in the air. And based on what I’ve seen killed dead on the altar of Agile (and it ain’t been pretty) here’s what I think will happen next.

Remember all those burndown and velocity tracking applications The Powers That Be bought for Scrum? They’re not going to go to waste: Get ready for micrometrics.  Practically everything a team does will be measured, analyzed and acted upon by project managers. Going over checkins and having a thousand eyes on things is going to be horse and buggy stuff. We’re going to see utter exposure of everything that goes into the head and out of the fingers of developers, every cotton pickin’ thing will be timestamped, correlated to features, and graphed during reviews (which will happen in real-time).

In the new world of micrometrical software, no sparrow will fall without a burrowcrat getting on someone’s case about it.

How long did it take you to fix that bug this morning? What source code did you call up? How many steps did you take in the debugger, and what did you look at? What unit tests did you actually write and run?  Did Joe, the dev next to you, fix a similar bug in less time, with better quality? How much email went back and forth about the issue? Do you often mis-spell keywords? Do you hit backspace a lot, or change your mind about function names or parameters? Does it appear that you know exactly what you’re doing?

What percentage of your keystrokes and mouse clicks and minutes of your day can be mapped to a product feature?

My guess is there are shops already doing this, where fractal attention to detail has become a recursive ass-covering game, and everyone has forgotten why they started writing software for a living.

Has it been that long? When was the last time you enjoyed making a hunk of code work?

Please, have fun every day.

My new favorite way to get rid of spiders in our house (they are welcome anywhere outside, but not in the house proper, and not in the garage) is to whooshify them with the shop vac. This is safe and efficient because with my superior engineering skills and some duct tape I’ve added an extension wand about yayyyy long to the existing extension wand’s extension. With my corrected vision I can spot a black widow spider from 20 feet away, and now that I have developed the capacity to whooshify them from a distance greater than their pouncing radius, life is better.

Except . . . I have this new irrational fear of vacuum cleaners.  Umgekehtervacuumenspiderenwhooshenobia is the phobia that a vacuum cleaner will experience a sudden polarity reversal and spray several years worth of very much alive and probably quite vexed poisonous spiders around the room. Hilarity ensues.

- – - -

In the software industry, the practice which is most like saving up poisonous spiders in a big bag for a later, less convenient time is the creative denial we call Bug Triage. It’s got other names, such as Managing Customer Expectations, Meeting the Quality Bar, or Getting the Fucking Project Shipped, but it all comes down to one thing: Stuffing defects into a bag (a “backlog” or similar purgatory) and getting the stupid collection of bits to paying customers without the bag or the customers suffering a catastrophic reversal of fortune.

The dirty truth of software is: It’s buggy. From the crappy hacks that run your toasters and flatscreen TVs to the expensive professional-grade stuff that keeps nuclear reactors from running amok and spewing out gigantic radioactive spiders, if something’s got a couple kilobytes of code in it, chances are it’s also got some pretty tasty bugs. We’re just not good enough as a species to put together a gadget with a few thousand parts without risking something blowing up.

Most of the time we don’t see them. Or if we do, they are minor annoyances — who cares if your smart toothbrush crashes?  However, occasionally there is a howler.  Some ship team’s pure, distilled denial lets something through that should have been an easily identifiable must-fix bug.

The truly pernicious bugs are the ones that don’t actually look like bugs. You think you’re happily slinging code around, and one day you wake up and realize that you’ve filed sixteen TFS reports in the last day, all about the same simple problem. You think harder and discover that other groups — people that you’ve never even heard of — have been holding daily war meetings about this bug. Six PMs and three managers are asking about status. (The actual issue? It’s a cosmetic thing affecting the color of a button in an error message, a one-character fix where a less-than should have been a greater-than).

The system has eaten itself, and you’re mired in a toxic, icky pool of process. You’ve become a living part of the bug. Your job? To keep the bug handling system alive by making more bugs. The bug-handling ecosystem has evolved to florish on the bug-making process, and if there aren’t enough bugs, it will make up some of its own.

My advice is: If it gets this bad, either get promoted so you can start lobbing hand-grenades into the machinery, or do something else.  Trust me, the system won’t miss you.

[Scene: The early 90s, in an office of a certain Silly Valley computer manufacturer]

“I’ve got a great idea.”

“Shoot.”

“You know how old programmers are usually overrun and crushed by the young turks? These kids are fresh out of college and can crank out C and C++ faster than us experienced old farts. I’m sick of that.”

“Me, too. That last intern who re-wrote the kernel page management…”

“Worst review of my life, yup. So, why don’t we design a new language, all whizzy and structured and garbage collected and stuff, and — get this — utterly isolated from the OS.”

“Like BASIC?”

“Right! So they can’t do anything real in it.”

“I get it. It’s a teaching language.”

“No, we sell it as if it was a real language, too. That way colleges are sure to teach it. And it’ll cripple our competitors once they latch onto it.”

“Neat.”

“Now the kids will come out of college knowing essentially nothing about processors, or memory systems, or I/O — hell, they’ll never even have heard of exclusive-OR — and they’ll go into companies thinking they know everything. And in ten or twenty years . . .”

“We keep the castle safe for us. They can’t touch the kernel. We give them a miserable excuse for a native call layer, use blocking I/O everywhere, and give them X-Windows style graphics for user interfaces. Yeah. I like it.”

“What should we call it?”

Sorry, Amazon. Even though I’m a relatively new Kindle owner, with eyes that still sparkle at the phrase “Buy now with 1-Click,” and even if I’m still a little giddy at sub-minute delivery, I’m not going to shell out 17 smackers for the first Stephen King book in two decades that I might just possibly want to read.

Drop the price seven bucks, and we’ll talk.

My first SF convention was in 1976 or thereabouts, and Frank Herbert was Guest of Honor. I skipped a whole day of 9th grade and later caught hell from my parents, but it was worth it. [This was the year I failed Typing, which is probably the reason that I'm an Emacs user.]

Frank talked about his recent book Children of Dune, and since this was during the US’s early days of Really Heavy Ecology he talked a lot about saving the planet. I forget the particulars. Desertification, human impact, and how we’ve got to get off of this rock, mostly.

The only thing I remember clearly was when he mentioned there was another Dune book on the way. A bearded grad student next to me muttered, “Yeah, Streetsweeper of Dune” and the people around us laughed.

So it was bad, even then, when he was still alive and actually writing the stuff.

There’s another Dune book coming out, Sisterhood of Dune. These things are being pooped out about twice a year, it seems. I haven’t tried to read any since I threw away my first “Dune prequel” — right now, I can’t even remember the title. The series is dead to me. I wish there was a way I could “negatively buy” a book, somehow push it back in their faces as Do Not Want material.

How fast they grow. This morning, our 7 year old discovered how to open child-proof caps.

A cow-orker of mine once bragged about the DateTime class he’d written.  “It’s fantastic,” he said, “It handles dates from 10,000 BC to 10K AD, down to the millisecond. It does all the correct calendar conversions.  It knows about September, 1752. We don’t have to worry about our time API now.” He left the company a couple months later, and we shipped and started getting bugs from customers.

Most of the features he’d written were great on paper, but he’d never written effective unit tests. The code had a bottleneck that funneled everything through Unix time functions. Nothing prior to 1970 worked, nor anything past the Day of Armageddon in 2038. There was code to handle leap years, but it failed every 100 years.

I rolled up my sleeves and got into it. It was surprisingly hard to get it right. I spent about two weeks writing unit tests and making the thing work as advertised. Our start-up had a really neat smart messaging protocol with date/time as a basic type — we figured that since so many of our customers were getting it wrong, that we’d get it right and leverage that as a feature.

Something about “Those whom the Gods destroy they first make proud,” right. This is a class of problem that everyone knows is trivial. “Of course I know how to do this,” you probably think to yourself, “This is trivial, I can just code this thing up and have an early lunch.” Trivial is the most dangerous word in all of computerdom, it’s a misprounciation of “Evil”. Your blood should run cold if you hear it spoken out loud, because the Gods will be listening carefully and taking notes on how to screw you if they ever hear you say it.

When you deal with time, you have a number of choices.

• What is the range of times you handle? Computer-era scale? Human (historical) scale? Geologic scale? Ridiculous death of the universe ranges, when protons have decayed, all galaxy-sized black holes have utterly evaporated and even Twinkies have gone a little stale?
• What resolution do you need? Particle accelerators probably need jillionths of femtoseconds, for instance. Computer-scale times are probably on the order of hundreds of nanoseconds. Human-perceptible and most real-time processing can be done in milliseconds. Geologists don’t give a shit about a stretch of time less than a hundred thousand years.
• What about daylight savings time? Time zones? Leap seconds? All the people who get this stuff wrong in the real world?
• Do you need the ability to compare times? (This becomes an issue when you deal with some other time formats, for instance OLE uses floating point numbers, days since some epoch, and fractions of a day, and so representing 10AM exactly is impossible).

That’s just time; we’re not even getting into “date” issues like calendars, or holidays. Holidays are serial nightmares on roller skates.

I believe that most programmers (including this one) do not really understand time. It gets worse, though, when you have to deal with a hardware clock that was designed by a hardware engineer who not only did not understand time, but also failed to devise a way to reliably extract it from the circuit he designed.

“You set the Freeze register and wait, then read the value.”

“How long do I wait?”

“Um . . . about, well, a while.”

“How long is a while, given that this is the hardware that’s supposed to be telling me how much time is passing?”

“I guess you can just delay or something.”

So one of us is going to Hell because we have to turn off interrupts and spin for half an eternity, just to find out what time it isn’t any more. That tick you were interested in? Sorry, it happened while we were busy waiting for some moron of a flip-flop to make up its mind. See you last year.

Recommended reading: Calendrical Calculations. This is a really great treatment of time and calendars, and if you are writing any code in this area you should definitely read the first few chapters and then crawl under a desk and quiver, wondering how anybody gets this stuff right, ever.

Oh, and personal to you-know-who-you-are: I hope you are writing some bloody unit tests now. Right? Okay?

What I Wore to Work on Thursday

Sweatshirt I bought at the Apple company store in the early 1990s. I worked there from 1987 until 1994, and didn’t overlap Steve at all — just Scully and Spindler. I missed Gil as well — I hear I didn’t miss much.

No bad comments at all. (I was surprised it still fit ).

I had an HP calculator, a 25C, in the 70s. I programmed the living crap out of that thing; 49 program steps, 9 or 10 memory locations, and a four level stack, and wrote programs that used every single bit of that memory.

My dad had a series of HP calculators, notably an HP-65 with a card reader. I kept bugging him to bring it home so I could hack on it all evening, at our kitchen table.

Our high school had a great HP computer and plotter (I didn’t get to use it much, but it was cool).

Once upon a time I lived near the HP plant in Loveland. I was in 10th or 11th grade. I remember riding my bicycle five miles to the plant, announcing myself as a computer hacker and could I have a job? The receptionist was less than impressed. I did get to talk to one of their engineers, and he was bemused and maybe a little impressed, but they couldn’t hire a high schooler even if he had built a computer over the winter. Later I went to an open house and spent hours mucking with the test equipment they had set up and asking questions about their chip processing plant.

I used an HP 6502 emulator at Atari to help debug video games. I used HP analyzers at Apple to find out WTF was going on inside the Newton, when I couldn’t use a debugger. I used HP analyzers to grok some gnarly 68000 timings.

I know how to program a 41C in its native machine code. I’ve read the specs on the CPUs in the calculators. I learned what CORDIC was because that’s what made the original HP 35 tick.

I have an HP 41C, two HP 48s, a 32S, two 16Cs, and probably one or two more that are hiding in boxes. (I wish I still had the 25C, and I covet my dad’s 65). I have an HP x86 laptop in the garage (my dad gave it to me a few years ago. It runs DOS and weighs about ten pounds and almost certainly still works though it’s 20 years old).

It was nice to know HP, when it was a company that mattered.

HP as a company is dead to me; they have no products that I am interested in. Any magic that was there fled years ago, and the recent mismanagement is just the natural process that a nearly dead company goes through on the way to termination. I feel sorry for the people who are working there. I wish that HP made something cool, but they don’t any more, and that will be the end of them.

The R1100GS I bought in 1995. What a great bike; it’s done tons of highway and some off-road miles, and never let me down.

In with the new; an R1200RT:

I’m still getting used to it, and I’m deliberately not using all the fancy, distracting buttons and switches until I’m totally comfortable with it. For example: BMW got rid of their old turn signal switches (a directional button for each thumb) and now uses a traditional rocker switch on the left thumb now; it’s harder to signal, and I have to practice.

On this morning’s commute, compared to the GS I felt like I was in a bubble of air; the amount of wind and noise was dramatically reduced. I guess that’s the whole point of a touring faring.