Archive for July, 2012

Sometimes, Fast Eyes Aren’t Enough

Wednesday, July 25th, 2012 by The Director

I know, you’re saying, “The Director, you have the fastest eyes I’ve ever seen.” Well, probably not, since you might not have ever seen my eyes. But in my years as a printer, which meant I operated a Web printing press, which does not mean I did anything with the World Wide Web (the recruiters I talked to in the early part of the century looked crestfallen at that admission) but instead meant that I was responsible for the quality of printed material moving past me at 100 feet per minute or more. So I have a great skill at seeing problems with redirect pages and loading messages that most of the time only display for a fraction of a second.

But even I, ol’ The “Quick Eyes” Director, use a dirty trick to see what the user most likely will not: I take a screenshot of the loading message to check it.

You don’t have to get too fancy with it; when you see the screen, press Print Screen on the keyboard. That captures a bitmap of your screen to the clipboard, and you can paste it into Microsoft Paint or your preferred image editing software, and you can review it at your leisure. You have to press the key immediately when you see it, so it’s a test of your reflexes as well, and it might take a couple tries to get the screenshot. It helps if you say, “Big money, big money, no Whammies, STOP!” as you try it (so you can test like the other Michael Larson, word).

Note you can do the same thing on the Macintosh using Open Apple Command+SHIFT+3 or whatnot, but that’s a lot of synchronous button mashing, so it’s easier with a Windows machine.

Or if you have screen recording software that allows you to play the screen back at slow speed, you can review these messages very easily.

The point is, you can check the spelling, layout, and behavior of messages like this:

The elusive loading message

And you don’t even have to serve several years covered in spots of Reflex Blue ink to do it.

Hiring Tip

Tuesday, July 24th, 2012 by The Director

I Won’t Hire People Who Use Poor Grammar. Here’s Why.

Now, jump right into it and look for a grammar error to prove your worth. Or merely snicker at the unfortunate URL. Or both.

The Unfriendliest Friendlies

Monday, July 23rd, 2012 by The Director

Hey, look, it’s a spammer who might test:

From the test client?
Click for full size

Or is it a phishing operation targeted to QA, whom the attacker just assumes would open an email marked test like some salivating dog?

You be the judge.

STOP THE PRESSES ELECTRONS! BREAKING NEWS!

Wednesday, July 18th, 2012 by The Director

SD Times releases a bombshell: The Great Migration: It’s harder than you think (that’s the print title; the Internet title differs).

It’s a SPECIAL REPORT on the difficulties of migrating legacy applications to modern technologies, and it’s explains that it’s harder than you might think.

If you are a twenty-something developer or IT manager thinking that it’ll be a snap to go from a bicycle to a motorcycle or a tricycle to a race car (as one set of adverts puts it) or a joystick to a PS2 controller (as another set puts it). You get into a lot of trouble with that sort of thinking, the, erm, agile mindset of start slapping things together in .NET and you’ll be golden.

Many of my jobs have involved projects of this sort. Going from OS/2 to Windows, going from SPARC to Windows, going from Open VMS to going from mainframe to the Web, and so on.

The basic mistakes are similar in nature:

  • Starting with inadequate understanding of the product/industry/domain and writing something that crystallizes and entrenches the misconceptions deep in the code, in the data, and in the process.
     
  • Going forward with inadequate input from users who, you know, actually use the software and understand their workflows and needs.
     
  • Choosing the wrong new technology to build the modern tech equivalent of a legacy application. And sometimes having to back up and start over after following the wrong path for a while.
     
  • Expecting too much too fast. Legacy applications evolve over the course of years. Expecting to rewrite it in toto in six months or a year is asking for heartache.
     
  • Giving users too much leeway for change. As the article notes, the migration gives organizations the chance to change processes and software workflow to better suit their modern needs, but these projects run into trouble when the users have the ability to shake the Etch-a-Sketch up with a lot of code, porting, and refactoring already done.

Application migrations harder than you think? Not me, brother; I assume that a legacy migration is plenty hard. It’s harder than starting from scratch.

What Makes A Developer A Developer?

Friday, July 13th, 2012 by The Director

Andrew Binstock doesn’t ask that question. He asks: What Makes Bad Programmers Different?

You say tomato, QA says tomato paste, tomato sauce, ketchup, catsup, salsa, roast tomatoes, tomato juice…..

But I digress.

Binstock highlights these traits of bad developers:

The bad programmer in action is best described by Daniel K. Lyons, who put forth the following list of traits as a comment on my previous editorial. The traits are:

  • Their code is large, messy, and bug laden.
  • They have very superficial knowledge of their problem domain and their tools.
  • Their code has a lot of copy/paste and they have very little interest in techniques that reduce it.
  • The fail to account for edge cases, while inefficiently dealing with the general case.
  • They never have time to comment their code or break it into smaller pieces.
  • Empirical evidence plays no role in their decisions.

I believe that most bad programmers participate to varying degrees in all these activities. They rarely fail to specialize in just one, alas.

I’d say these are not just traits of bad developers, but that most developers exhibit one or more of these behaviors from time to time.

But, yeah, I’ve seen worse developers. These are the ones that frustrate and upset other developers. Fascinating, the anthropological study one can do on developers and their tribes.

Binstock links to his list of things that make great developers different.

Want to know what makes a great developer? He or she has the same neurosis for quality that I do.

If You Thought Time Sheets Were Fun….

Tuesday, July 10th, 2012 by The Director

I used to work for a company obsessed with time sheet metrics. It went through three or four iterations of time sheet solutions while I was there, from Excel spreadsheets to a roll-your-own solution built from the ground-up to an off-the-shelf solution that required a bunch of customization before launch. Maybe that didn’t even actually launch when I was there. Maybe, instead, it launched after I was gone and then was replaced shortly thereafter with something else.

Yes, I understand the impulse to track as much as possible down to the minute, but when you’re in a multiple-customer, multiple-project environment where you’re switching between the clients and projects many, many times in a single day, you get a lot of signal loss in spending a couple minutes a day entering information into a time sheet for a couple minutes’ worth of actual work. Suddenly, you’re billing as long for time sheet entry as actual work. Or you’re filling up some non=billable catch-all bucket called “Administration” or “Non-Project” with minutes. Worse yet, if you’re switching tasks from crisis to crisis (sorry, I meant opportunity to opportunity) and you get to the end of the week with a time sheet that says you were only on the job twelve hours that week, you have to go all TSI on it, and forensically guess whether you spent six minutes or twelve minutes on that project on Tuesday.

Fortunately, or unfortunately, technology is bringing new solutions to bear:

Imagine how much better workers could do their jobs if they knew exactly how they spend their day.

Suppose they could get a breakdown of how much time they spend actually working on their computer, as opposed to surfing the Web. Suppose they could tell how much an afternoon workout boosts their productivity, or how much a stressful meeting raises their heart rate.

Thanks to a new wave of technologies called auto-analytics, they can do just that. These devices—from computer software and smartphone apps to gadgets that you wear—let users gather data about what they do at work, analyze that information and use it to do their job better. They give workers a fascinating window into the unseen, unconscious little things that can make such a big difference in their daily work lives. And by encouraging workers to start tracking their own activities—something many already are doing on their own—companies can end up with big improvements in job performance, satisfaction and possibly even well-being.

Frankly, that could be helpful, I suppose. Or it could be maddening from the point of view of the actual worker.

The key word here is encouragement. It is not the same as insistence. Bosses should be careful to stay out of workers’ way, letting employees experiment at their own pace and find their own solutions. They should offer them plenty of privacy safeguards along the way. Too much managerial interference could make the programs seem like Big Brother and dissuade workers from signing on. There’s a big difference between employees wanting to measure themselves, and bosses demanding it.

So which do you think it might fall out in most places?

Yeah, me, too.

Might Also Work on Automation Software Vendors

Friday, July 6th, 2012 by The Director

What to Do If There’s a Mountain Lion in Your Office.

Remember, the door is your friend.

Good News For Security Testers

Friday, July 6th, 2012 by The Director

A recent court ruling might put banks on the hook for additional losses due to fraud:

In the PATCO appeal, the court rules that Ocean Bank increased PATCO’s risk of fraud by allowing wire transfers to be approved through only the answering of challenge questions for any transaction exceeding $1.

The ruling goes on to say that even when the bank had warnings that fraud events were likely, as in the PATCO case, it “neither monitored that transaction nor provided notice to customers before allowing the transaction to be completed.”

The fraudulent wire transfers that hit PATCO’s account should have raised red flags and triggered extra security measures to validate the transactions, the court says. “The payment orders at issue were entirely uncharacteristic of PATCO’s ordinary transactions,” the ruling states. “These collective failures, taken as a whole, rendered Ocean Bank’s security procedures commercially unreasonable.”

The Second Great Kludging begins. Let thousands of billable hours bloom!

Details, Schmetails

Wednesday, July 4th, 2012 by The Director

At the bottom of the Yahoo! IM client, the Match.com ad misses on critical detail:

Chat with, uh, men?

His Sinking Feeling Trumps Your Sinking Feeling

Tuesday, July 3rd, 2012 by The Director

Remember that one time someone brought to your attention a catastrophic or dramatic defect or problem that you might have and probably think you should have caught? Remember how everything got distant and hollow as the blood pounded in your ears?

Yeah, your sinking feeling probably pales in comparison to this guy:

It’s Friday, and as the software testing team heads home for a three-day weekend, they forget to turn off a 250-server cluster they’ve been renting from a public cloud infrastructure vendor. The cluster doesn’t have a job to run, but it still racks up a $23,400 bill, 10 times what was planned. “It went from $2,300 to $23,000 so quickly,” the testing team leader explained when he got back.

It’s a true story recounted by a software company CEO, and it points to a major concern that would-be cloud buyers have: runaway costs.

That, my friends, is a bad start to a week.


wordpress visitors