Archive for February, 2014

QA Music: You’ve Got Another Thing Comin’

Monday, February 24th, 2014 by The Director

Gather round, children, and listen to the music your parents would have listened to if your parents were awesome:

That’s Judas Priest. Go look it up in your history Kindles.

A Car Guy’s View of Software Development

Tuesday, February 18th, 2014 by The Director

In this case, the development of software automobiles:

Once upon a time, software was written by people who knew what they were doing, like Mel and his descendants. They were generally solitary, socially awkward fellows with strong awareness of TSR gaming. They were hugely effective at doing things like getting an Atari 2600 to run Pac-Man or writing operating system kernels that never crashed, but they weren’t terribly manageable and they could be real pricks when you got in their way. I once worked with a fellow who had been at the company in question for twenty-three years and had personally written a nontrivial percentage of the nine million lines of code that, when compiled, became our primary product. He was un-fire-able and everybody knew it. There were things that only he knew.

This kind of situation might work out well for designing bridges or building guitars (not that Paul Reed Smith appears to miss Joe Knaggs all that much, to use an inside-baseball example) but it’s hell on your average dipshit thirty-five-year-old middle manager, who has effectively zero leverage on the wizard in the basement. Therefore, a movement started in the software business about fifteen years ago to ensure that no more wizards were ever created. It works like this: Instead of hiring five guys who really know their job at seventy bucks an hour each, you hire a team of fifty drooling morons at seven bucks an hour each. You make them program in pairs, with one typing and the other once watching him type (yes! This is a real thing! It’s called “extreme programming”!) or you use a piece of software to give them each a tiny bit of the big project.

This is what you get from a management perspective: fifty reports who are all pathetically grateful for the work instead of five arrogant wizards, the ability to fire anybody you like at any time withouiret consequence, the ability to demand outrageous work hours and/or conditions, (I was just told that a major American corporation is introducing “bench seating” for its programmers, to save space) and a product that nominally fulfills the spec. This is what you get from a user perspective: the kind of crapware that requires updates twice a week to fix bugs introduced with the previous updates. Remember the days when you could buy software that simply worked, on a floppy disk or cartridge, with no updates required? Those were the wizards at work. Today, you get diverse teams of interchangeable, agile, open-office, skill-compatible resources that produce steaming piles of garbage.

He doesn’t speak about xth generation languages, which allow the software to be badly written far away from and with little knowledge of the hardware it’s running on by developers without knowledge of it and who are forgiven by advances in that underlying hardware (and now virtual hardware) that can cover-up some poor design and coding practices, third-party components of dubious provenance relied on for core processing, and Internet cut-and-paste.

But, other than that, he explains very well why my next car is going to be a Mercedes. A Mercedes 35 hp.

(Link via.)

This Is Too Simple To Be A Tip, Isn’t It?

Tuesday, February 11th, 2014 by The Director

In my automated test scripts, I always put one-line comments at the end of loops and methods that show what is closing. For example, in Ruby, it looks like this:

    puts("Waiting for delete confirmation")
    sleep(1)
  end #until
end   #click_delete_yes

It makes it just a little easier to figure out where I am in the code, and it also makes sure I close the loops and functions appropriately.

That’s so simple and obvious it can’t possibly be a helpful tip, coud it?

Seahawks-Tested (Almost)

Tuesday, February 4th, 2014 by The Director

A game player tries to score 1000 points in Madden NFL 25, but instead finds a defect at a common point:

About 10 minutes into the game, I had scored 262 points. The above score is actually wrong. We’ve run into this problem before: once you get to 255 points, Madden stops counting correctly. Not that it doesn’t try.

At the bottom, it says the Seahawks have scored 255 points. At the top, 266. Neither was correct, and I was pretty amused that a computer could attempt the most basic of tasks — addition — and come up with two kinds of wrong.

From what I saw of the actual Superbowl yesterday, this is uncannily accurate.

Remember, friends, in QA numerology, 256 is a magic number. You should try it out even when there’s no explicit boundary stated for an action or a variable. Along with magic numbers like 1025, 65537, and other talismanic digital sequences.

(Link via tweet.)

QA Music: An Ode to the Itinerant Tester

Monday, February 3rd, 2014 by The Director

Five Finger Death Punch, “Battle Born”:


wordpress visitors