Software development has broken our hearts. It’s time to burn down the trailer park:
On a personal note, when I lived in a trailer park, we were in a trailer larger than an Airstream, but 12″ by 60″ is about the smallest you can get in an actual mobile home. And burning down an entire trailer park would take more effort than you think.
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.
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.)
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?
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.)
Five Finger Death Punch, “Battle Born”:
An essential quality of a good manager is the desire to seek bad news rather than deny it. An effective manager wants to hear about what’s going wrong before he or she hears about what’s going right. You can’t react appropriately to disappointing news if it doesn’t reach you soon enough.
You concentrate on bad news in order to get started on the solution quickly.
That’s my philosophy, too. And I share bad news willingly.
Beginning next week, your software users might bring with them some new email addresses and URLs as new top-level domains become available:
Starting Jan. 29, the first of hundreds of new top-level Web domains—the suffixes that appear at the end of website addresses like .com and .net—will become available for the first time in more than a decade.
Seven Web domains will be released next week, including .bike, .clothing and .singles. The new domains are expected to draw interest mainly from entrepreneurs and small-business owners seeking Web addresses that more closely relate to the products and services they sell than the Web addresses that are currently available to them.
This means that any part of your application that validates email addresses or URLs might need to get a little exercise.
Duran Duran, “Wild Boys” from 1984, which is before the internal clocks of many of our compatriots in this industry began, the damn kids.
In 1985, I wanted to look like Simon Le Bon. In 2013, now that he’s 55, I’m closer than ever.
I clicked through a retweet to an article entitled “Which Programming Language Should I Learn First? on Lifehacker.
And then I almost fainted when I saw the sample code they included for Hello, World programs.
As you know, gentle reader, I’ve often thumped tubs about how any program used to teach students and that outputs Hello World is teaching the youngsters to program defects at the outset because, as “World” in this instance is a noun of direct address, it should be offset by a comma (Hello, World).
So when I saw the sample code included, where the programs for Java and C have that very comma in them, I was amazed. I had to immediately tweet about how it changed my life.
But then I looked closer: In addition to Java and C, the article includes samples of Python and Perl. And the commas are missing.
So I guess it’s more of a crash course in development than the writer intended.
It’s a collection kludged together, and nobody’s going to think to check consistency or know if there’s a problem in different areas of the software except for QA. Because the milestone and the deadline were met.
In North American football, the offense sometimes runs a draw play, which is a delayed handoff that gets the moving parts of the defense to act before the offense turns the ball over to its running back:
The idea behind a draw play is to attack aggressive, pass-rushing defenses by “drawing” them downfield. This creates larger gaps between defenders and thereby allows the offense to effectively run the ball. Draw plays are often run out of the shotgun formation, but can also be run when the quarterback is under center. These types of draw plays are sometimes referred to as “delayed handoffs”. The running back will most often run straight downfield through the “A-Gap” (the space between the center and the offensive guard), although there are more complicated variations.
Now, in our deadline-driven software development world, we often find ourselves typing and clicking as fast as we can to get as much test coverage as we can in our allotted time. In a way, we’re playing to software that’s trained to be aggressive linebackers, running toward our software’s operations as fast as possible. Kinda like I started charging into this metaphor too quickly and find myself off-balance, unable to elegantly segue to my point.
Within applications, you can sometimes find defects by delaying actions. If your software integrates with other software or services asynchronously, the expectations of the code might not match how fast–or slow–a user might interact with the software.
For example, a shopping cart piece of e-commerce with distinct units might mark those units as Hold, Wait For Payment if a user adds it to the shopping cart and starts the payment process. If the hold has a timeout associated with it–an expectation that, if the user does not complete the payment within five minutes (or two minutes, or twenty minutes) that the payment has been abandoned and the system should remove the hold. However, in the case of paying with PayPal, the PayPal window itself can linger for that duration and more, ready to accept your login and confirmation of payment, at which time PayPal will send a payment received message to your system. For an item whose hold might have been relinquished and might not be available any more. How will you know unless you hold onto that ball for a a couple of seconds and let all the integrated software make their plays?
Another example: Financial software that uses two stages of authentication. The first time you log in from a browser, it prompts you for your user name and then directs you to a security question; after you answer that correctly, it prompts you for your password. If you log in and don’t do anything for ten minutes, your session times out. But what happens if it takes you longer than ten minutes to answer your security question? What happens if you answer the security question but don’t enter a password in those ten minutes?
The draw test is a valid line of testing because your users don’t live to fill out your forms. In their real lives, they’re called to meetings, go to lunch, minimize the browser window when a co-worker comes in, or otherwise temporarily delay their activity in a fashion that might put their next actions beyond your software’s expectations. If you take a little time, you can identify the places where your system might allow this and to make sure your software handles delayed action on your user’s part elegantly.
Developers, listen to the kind man Frank Hayes as he explains you should never set the cat on fire:
QA: Do just the opposite of what he says except for the first verse and the cat thing.
I wish someone would ask me that question in an interview just so I could say, “A squirrel.”
A half-crazed Mississippi squirrel.
Not me, and not really the magazine. It’s only the Web site, but it is Ben Simo:
Nearly 20 million Americans have now experienced the broken Obamacare website first hand. But Ben Simo, a past president of the Association for Software Testing, found something more than a cumbersome login or a blank screen—clear evidence of subpar coding on the site.
Congrats, Ben!
Cracked (I put the name in italics because it was a magazine in my day, sonny, and I fancy myself the IT world’s Sylvester P. Smythe) has a piece entitled 5 Reasons Tech Companies Make Bad Gadgets (An Inside Look) that you might want to read.
It’s not about software per se, but it looks awfully familiar.
A quote commonly attributed to Napoleon says:
Rascality has limits; stupidity has not.
I’m testing this application as rascally as I can, but I am only one member of the team, and the users are infinite monkeys with infinite typewriters and hammers and stone tablets.
Am I being stupid enough? How can I be more stupid?
Long-named US woman celebrates government climb-down:
A US woman has won a battle to have her full name put on her driving licence.
Janice “Lokelani” Keihanaikukauakahihuliheekahaunaele’s name is so long – containing 36 letters and 19 syllables – that it would not fit on the documentation.
What is the lesson here?
The obvious lesson, of course, is that you need to consider names other than Mike Smith when building your applications. Of course, we’re pretty much past that now given our more worldly software development culture (people who build and alter government computer systems not included, of course).
But you’ve got to test those long strings going into the system, and you’ve got to test those long strings coming out of the system.
If you’re displaying someone’s name, does the name lie over other design elements on the page or, urk, the mobile app? If it’s printing out somewhere, is there room on the page or in the PDF for it?
You’ll never know until you try. Your developers will never know until you try, either, because they won’t try it themselves.
(Link via Tweet.)
Apparently, there’s an Android game called Send Me To Heaven that… Well, I can’t explain it any better than:
S.M.T.H. (Send Me To Heaven) is a sport game. Player throws his phone as high as he can. The higher, the better. The phone registers the height and uploads result to leader boards. World Top 10, Week Top 10 and Day Top 10 lists are available.
That’s about the funniest thing I’ve read all week.
Apple, though, rejected it.
Five Finger Death Punch, “Lift Me Up”.
Language warning.
Motorcyclist survives lightning strike while riding on freeway:
A motorcyclist riding on Interstate 5 survived a lightning strike Thursday as a tumultuous day of weather saw thunderstorms and rain roll through Washington on both sides of the Cascade Mountains.
The biker was riding through Chehalis in western Washington when the lightning hit Thursday morning, Washington State Patrol Trooper William Finn said.
Remember, remote chances of a bad thing occurring are not the same as no chance, and you need to assess your risk accordingly. Individually, people have a very remote chance of winning the lottery, yet someone wins the lottery every couple of weeks.
Make sure when assessing your risk, calculate in the severity of the problem and the number of users mashing the keys in addition to the remoteness of the possibility of that happening.
