Feedback

In which our readers decry cheap labor, take issue with Mr. Ambler’s UIs, grow bellicose about Breeze, and go on—and on—about Google.

For the past 15 years, U.S. corporate management teams have experienced a real hemorrhage of technical expertise. U.S. companies are filling up on managers with empty business educations who avoid learning the technical details of the projects for which they’re responsible. I call it the “Big Mac” effect. In fact, corporations have special fast-track programs for these people, in which they switch jobs so often that they’re gone before they’ve had sufficient time to learn anything. It’s the “drive-through” or “drive-by” effect—depending on whether coworkers in the organization were “taken out” or the person leaves behind any collateral damage. However, the real crime is management personnel who lack the ability and instinct necessary to lead. I call that the “super-size” effect, in which people are “super-sized” into leadership positions they can’t handle.

On the technical side, folks either do or die—or bow out on their own. Incompetent technical folks don’t go very far, as they’re unable to hide behind their lack of skill.

The law of supply and demand works the same way for labor as it does for the good or service being produced. Corporations continue to seek ways around the natural forces of capitalism’s supply and demand when they dilute the labor force with cheap overseas labor. Furthermore, the notion that the U.S. has a desperate need for $5-per-hour labor is self-destructive. If Adam Smith had heard our Harvard MBA president talk about needing cheap Mexican labor to satisfy our labor shortfalls, he would have slapped him silly.

I urge you to do the math. How far do you think a wage of $5 per hour will go? When a worker makes the minimum wage, who pays for his Section 8 housing vouchers, food stamps, medical care, transportation or his children’s education, among other services?

The U.S. economy needs balance in our workforce. It’s time our technical professionals demanded more analysis and honesty from their elected officials. After all, “In the rating of a ship, men mean more than guns.”

David Etkins
Software Engineer

BRAINSTORM AND PROTOTYPE
I just read “Usable UIs” (The Agile Edge, Feb. 2005), and once again, Scott Ambler provided your readers with some sound advice regarding usable user interfaces. However, I believe the piece missed the mark, as he offered only one example of a UI prototyping tool, and frankly, it was one fit for grammar school students. For those project managers (like myself) who don’t use a development tool like Visual Studio to design user interfaces, consider a tool such as Visio 2003 Professional to brainstorm and prototype the design of your UIs. This way, at least you have something that can be reworked prior to your client’s final approval, rather than being stuck with a static digital camera photo.

Drew Dodd
Project Manager

Visimation
Seattle, Wash.

Scott Ambler responds:
The AXLE Prototyping tool is fairly sophisticated, but it’s clearly aimed at the development community. Using a tool such as Visio to develop mock-ups works well, but can be time consuming. For UI brainstorming, I’d suggest using inclusive tools such as paper or whiteboards to work with your stakeholders. For specification writing, Visio is a good option because you can draw fairly sophisticated screens. However, as project manager, you might just get your developers and stakeholders together and have the developers build the actual UI using their development tool of choice. For this to work, you’ll need to train and mentor your developers in UI analysis and design skills—skills that every IT professional should have.

NO FLASH IN THE PAN
In “Taking a Test Drive,” (Special Guide to Demo and Presentation Tools, Feb. 2005), Mike Riley claims that Macromedia Breeze’s “insular use of Flash” hinders its broader adoption. This claim isn’t supported by Riley’s article, by Robert DelRossi’s longer review of Breeze in the same issue or by my own experience. Convoq’s own Flash player-based ASAP client is accessible from more computers than even a Java client would be, and it doesn’t require attendees to install anything. Furthermore, Flash Communication Server (which underpins both ASAP and Breeze) enables high-quality audio, video and presentations that aren’t plagued by firewall incompatibilities.

Dan Teven
Architect
Convoq
Lexington, Mass.

Mike Riley responds:
While I agree that the Flash player is more broadly distributed than the latest Java virtual machine, any deviation from the Internet Explorer browser (in the context of a PC environment) almost always requires a download and installation of the Flash plug-in. I know of several organizations that have switched from IE to Firefox, not only due to the security concerns, but also to filter out Flash-based advertising applets and non-value-add embellishments washing over many commercial-content websites. More security-conscious companies are also hesitant to install the Flash player black box due to past vulnerabilities and the uncertainty of the compiled delivery payload.

Although Macromedia has opened up its Flash specification, few third-party commercial or open source implementations exist, and those that do typically exhibit inconsistencies with the presentation files compiled by Macromedia’s commercial applications. Another problem lies in Macromedia’s inability to output its dynamic presentations to formats other than Flash. One could even argue that the adoption of the SVG standard designed to provide an open alternative to Flash was crippled by Macromedia’s decision not to provide SVG output

from its presentation products. This should come as no surprise, as such an alternative could have eroded consumer dependence on Flash technology, and thereby Macromedia’s business of proprietary authoring tool licenses and rendering platforms.

Flash does play an important role in the delivery of certain rich media presentations. However, when it comes to ubiquitous technology, open standards with access rules to the packaged elements, particularly those generated by an organization seeking maximum reuse among computing platforms and content rendering programs, will always be a more interesting alternative.

AN INVALUABLE RAT
Regarding Warren Keuffel’s “Geeks for Google” (Interface, Jan. 2005), a couple of generations ago, I took the IBM Programmer Aptitude Test (PAT). I must have done well, because IBM offered me a job; however, I went to work somewhere else.

At that company, we had difficulty finding a way to identify a good programming prospect other than putting him to work. My colleague, Jo Schommer, started giving the PAT to all the current programmers and reached the same conclusion as Mr. Keuffel: The test is useless.

She then collected every psychological test she could find and had us all take them. She found that the only test whose results matched her assessment of us was something called the Remote Associates Test, which consisted of questions like “What do the following have in common? (base, formal, foot).” The answer is ball.

Invented in 1962 and updated in 1967 and 1980 as a tool for studying creativity and intuition, in 1994 the test was used in research for a doctoral dissertation on implicit problem solving. No wonder it correlated well with the folks Jo was trying to select. She used it to put together one of the best groups I’ve ever worked with.

Mr. Keuffel’s column also brings to mind Victor Skowronski’s article “Do Agile Methods Marginalize Problem Solvers?” (Computer, Oct. 2004). Suppose you find a person who has the mental quirks that make a natural programmer. What will you do then? Throw a problem over the wall and wait for a solution to come flying back, or chain this unique individual to an oar and insist on one line of testable code every time the slave pounds the drum?

I’ve discussed the Skowronski article with my son, who’s a manager at L-3 in Salt Lake City. Having spent more than 40 years working my way from Fortran with Format to C# and VB .NET, I see the world from a problem solver’s viewpoint, but my son has to get the code produced, tested and shipped on time and under budget.

His counter to Skowronski is that fewer and fewer projects need problem solvers of the old school. What’s needed is a crew of adequate programmers who can implement the deliverables in the time available, and if it takes gigahertz and terabytes, so what? They’re cheap. Only when you’re deep in some embedded system where you can’t solve the problem by throwing hardware at it do you require a real problem solver, and no one does those any more.

James S. Taylor
Consultant
James S. Taylor and Associates
Stansbury Park, Utah

Warren Keuffel responds:
The Remote Associates Test sounds like the word analogy tests found in the LSAT and other graduate college admission tests. I suspect that seeing patterns is a useful skill for anyone involved in most creative intellectual endeavors.

MERE COLUMN FODDER?
I just read “Geeks for Google.” I must not be one of the “great programmers” Mr. Keuffel mentioned—I didn’t even have clever retorts to any of the questions on the test. On the other hand, I didn’t spend much time on it. So, like the author, I found it generally useless. Then, again, it did give him a topic for his column.

Mitchell McLain
Principal Software Engineer
Credence Systems Corp.
Hillsboro, Oreg.

THE TOP 2 PERCENT
I saw a GLAT ad in a recent issue of the national Mensa Bulletin, and found Google’s advertising choice interesting. Do they think Mensans are geeks (a common stereotype), or was Google merely trying to recruit geeks whose IQs are in the top 2 percent of the population?

Ruth Yoon
Denver, Colo.

CREATIVITY AND ITS ENEMIES
Regarding “Geeks for Google”: I’ve been a programmer for almost 25 years, and have met developers of all stripes, talents and quirks.

I had an immediate visceral response when I read Mr. Keuffel’s line “once you find good programmers organizations very often ‘kill’ them through insistence on certain programming ‘methods’.” In my experience, the real value of a programmer (how much quality work he can turn out in a given time period) is inversely proportional to his needing (or adhering to) guidelines, and his ability to follow methodologies, create flashy documents and so on. Almost invariably, the best programmers act intuitively. I’ve even noticed in my own work—when I’m in that Zen-like concentration-that-is-not-concentration (athletes call it “in the zone”), I do my best and fastest work. Answers to complex issues just come to me.However, when I’m bogged down with extraneous things, I get distracted and cranky, and wind up churning out “just-good-enough” stuff.

In other words, I agree with the author’s assessment of those “Is this a good programmer?” tests. I would just add that the work of the good, and the rare excellent, programmer can vary according to the degree of creativity that he is afforded at each stage, each moment, of the project. Oh, and having an office with a door helps, too. But I doubt I’ll ever see those days again.

P.S. You get extra points if my letter brought to mind the title of Virginia Postrel’s excellent book The Future and Its Enemies (Free Press, 1999).

David Beamer
Clawson, Mich.

Warren Keuffel responds:
I’ve heard of Postrel’s book but haven’t read it. Several years ago I wrote a column about getting in the zone, reporting on a book by a fellow who has studied this extensively—Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi (Harper Perennial, 1991). It’s a good book if you want to learn more about this phenomenon.

NOT ALL ALIKE
I read “Geeks for Google” with interest. I agree with Mr. Keuffel’s characterization of the Google Labs Aptitude Test as a PR stunt, although I believe Google must get value from it or they wouldn’t continue. (The Google Code Jam, which uses the TopCoder platform, is another program designed to engage problem solvers and create a candidate pool.)

As Mr. Keuffel suggested, little can be learned from an answer to one or two brain teasers. But ask a candidate to solve 12 problems by submitting code for each of them and measure the results against a pool of a few thousand who solved the same problems, and you have some compelling information that can identify some of the admittedly rare “good programmers.” Does that mean you don’t have to interview the candidates, or grill them about their communication skills and ability to work on a team? Of course not: Anything that could magically replace the need to vet candidates through rounds of interviewing, references and résumés would be a fortune-telling machine that costs each company millions. The fact that these people spend time and energy challenging themselves at the risk of failure reveals quite a bit about their characters.

“A well-done achievement test can be pretty useful in that it can weed out the bottom feeders.” By definition, weeding out the bottom feeders also identifies the top feeders who can repeatedly solve complex problems and write code that works against a large set of test cases. No one has months to spend finding these things out through “real-world” tests, so they do the next best thing: hire them and cross their fingers. For a company that receives as many résumés as I’m sure Google does, and given the fact that many of their engineers must stop what they’re doing to interview a potential bottom feeder, that’s millions of dollars useful.

Don’t lump all technical evaluation tools together. Some are more soundly designed and have a higher value than others.

Robert C. Hughes
President/COO
TopCoder
Glastonbury, Conn.