AJAX Goof

I’m glad to see some attention being paid to the stellar development framework of Rails (Rick Wayne’s “Railing on AJAX,” Nov. 2005), but there’s a glaring error in the article that is misleading (and could continue the perpetuation of an untruth): AJAX stands for Asynchronous JavaScript and XML.

Java and JavaScript are two very dissimilar languages: They’re not the same, nor is one a derivative of the other. To paraphrase the history: Sun was releasing Java at the same time as they were helping Netscape develop LiveScript. LiveScript was redubbed “JavaScript” to cash in on some of the buzz around Java, but in the long run the name managed only to confuse people.

It’s important to note that JavaScript is now just the common name for that particular language. Since the European Computer Manufacturers Association (ECMA) took over the management and further development of the language, it has been renamed ECMAScript (pronounced ek-ma-script). It’s a bit of a mouthful, but that’s the real name of modern JavaScript. (Not that AEAX would really have the same ring.)

Nomenclature is very important for ensuring universal comprehension in the written word and in discussion. We work in a world of many languages (both spoken and programmed), and it’s important that we all be on the same page.
Keep up the great work and thanks for keeping an open mind about new and developing application frameworks.

Aaron Gustafson
Senior Web Designer/Developer
Cronin and Company
Glastonbury, Conn.

Rick Wayne responds:
Thanks for bringing the error to our attention. As the one who made it, I only wish I had a cleverer response than “Oops.” As an act of penance, I’ll be slinking up to the blackboard to write “I do know the difference between ECMAScript and Java” 1,000 times. Having been raised in the days before refactoring IDEs, I still commit “Software Engineering by Copy and Paste” on occasion. Sadly, I did so here, propagating the text’s (single) misuse of Java into the deck. Excuse me while I get a box of chalk. A big box.

COMPENSATION QUESTION

Regarding the 2005 salary survey (“Holding Pattern,” Nov. 2005): Do the salaries shown include value-added compensation such as retirement and insurance benefits?

Edward Spencer
Salem, Ore.

Alexandra Weber Morales responds:
No, those are base salary amounts. We do track bonuses and stock options in separate questions, and report the total compensation in the written article but not in the tables. Since this is an employee survey, it stands to reason that most employees do not know the fully loaded cost of benefits to the employer (in our company, for example, the cost of benefits comprises 30 percent of the base salary, as a general rule).

HAPPY TRAILS?

Just some thoughts after reading your 2005 salary survey: We’re not in Kansas anymore—and neither is software development. Outsourcing, both on- and offshore, is here to stay, so how is a technologist expected to stay on this bucking bronco that seems intent on throwing us off?

It depends. If you’re not in Kansas anymore, where do you want to be—or, more precisely, what do you want to be? You might feel that your horse has taken a bit of a stumble as you see people riding past. You can grip the reins and settle down to ride with them, or you can let go and bounce through the sagebrush, only to get up and find some other pony to ride.

All of us will have to get off somewhere along the way, whether or not we pick our own time to mount and dismount. Remember the dot-com bust? There were more riders falling off horses than at Custer’s Last Stand! In fact, the cavalry didn’t ride to the rescue; instead, someone pulled the reins and most of the horses stumbled onto the “offshore development trail.” (Insert Roy Rogers and Dale Evans singing “Happy Trails to You.”)

The sound of falling bodies echoed across the plain for months. A lot of talented (and not so talented) developers were caught in Corporate America’s stampede to maximize shareholder profits. Some companies are still driving their wagon mules along the railroad tracks laid down by their competitors. Yet some have learned how to create a rich team of onshore/offshore developers and architects capable of producing quality software.

You can’t survive in this industry and be a stranger to the innovations and upheavals that have disrupted the technical landscape. In the mid-seventies, businessfolks and some software companies believed that developers were going the way of the Pony Express. We’d have software that was so easy to use even a manager could create a program, making all those longhaired developers obsolete! Guess what? We’re still here—and we’re everywhere, worldwide technologists, linked by an Internet that no one in the late sixties imagined was possible.

So, you might ask, “What good does this do me? I just invested four years in an industry that seems bent on destroying itself almost overnight.” First, nothing has been destroyedÑbut the landscape has changed. The Pony Express software days are gone. The demand is still there, and the excitement, too. If the demand isn’t strong, why are developers being trained everywhere all over the world? Clearly, there are a lot more and different horses running the race.

Take a good look! See that poor old swaybacked nag full of “coders,” so weighed down it’s barely stumbling along? People from all over the planet are jumping on and falling off at an alarming rate. With all those keyboards and monitors dragging behind, it’s a wonder the poor beast can even move, let alone deliver something useful. Management loves that old horse!

Nearby is a sleek steed carrying some actual software engineers. Some of the “coders” are revamping their skills and are being pulled up to sit beside them. These folks are arriving from the four corners of the earth, as well, but there’s something different about them. The horse is still crowded, but these “engineers” have even figured out how to hook a wagon to their horse! Some bright people hereÑthey deliver quality.

Watch out! Or you may be trampled by the management horse that’s trotting against the general flow. The accountants, who fell off their own horse a good way back, are close behind and trying to locate their elusive beast by counting each track they find. They’re sure that a fully functional horse will be found once everything is numbered and properly labeled on their spreadsheets.

Perhaps you can hop on management’s horse and get them turned around. If you’re really brave, you could lend a hand to the accountant posse. Once you’ve got these folks heading in the right direction, you might see a stagecoach full of software architects and lead developers. They’ve got a team and real transportation! If you hurry, you might be able to hitch a ride.

The point to this horse story? There’s nothing wrong with just coding. The choice, however, . does have some consequences. Being a mere coder might not be good enough in the future. Delivery of functionality for the business is the number one priority. A business doesn’t exist merely to provide technologists with the latest and greatest “toys.”

Good software people are generally self-made no matter where they come from. Just figure out which horse you want to ride and get going, no matter who is already on it or where they call home. Teach them what you know and let them teach you. If you’re one of the “good ones” or can train yourself to be, someone may even pay you for the horse you rode in on.

Cody Faile
Senior Technical Developer
Rock Hill, S.C.

THE TROUBLE WITH FICTION

The first three paragraphs in Robert Martin’s “The Trouble with Constants” (The Craftsman, Nov. 2005) are meaningless; can you enlighten me? The history is so flawed that I can’t imagine what it means.

Name withheld
Princeton, N.J.

WHOSE HISTORY?

I just finished reading The Craftsman in the November issue and have a question regarding the short history that appears at the article’s beginning. Did the meeting between the Axis leaders that Martin describes really happen?

Name withheld

Robert Martin responds:
No, this meeting did not actually occur. The events described are part of an alternate history that I’m writing as background to the Craftsman articles. If you go back through the previous articles, you’ll see that history in Alphonse’s universe begins to deviate from ours when Clyde Tombaugh, the discoverer of Neptune, also discovers a large asteroid on a possible collision course with Earth.

GREED VS. NATIONAL INTEREST

In your publication, the offshore development proponents have been quite vocal in extolling its virtues. I beg to differ.

In about 10-15 years, the standard of living in India, China and Russia will rise, and the salary gap will be narrowed to a point where it will make no sense to offshore anything (compare to car manufacturing in Japan—a bugbear of the seventies). Meanwhile, generations of U.S. computer science graduates will be lost and eventually will be replaced (at considerably lower salaries) by onshore immigrant workers. (Didn’t they raise the H-1B quotas recently? At least, these workers will pay local taxes.)

The very proponents of comparative advantage theory (the one that brought the current situation about) can’t help but notice that this time, the competitors are after our comparative advantage: the well-educated white-collar worker. How high up the value chain can it go? Though the economic demise of the U.S. might or might not occur, the future definitely doesn’t look promising without government intervention. A corporation is stateless; it owes its allegiance to its shareholders only, and is supposed to do what is the best for them. There are no (and should not be) such words as patriotism in corporate vocabulary. But this is where the government must step in to balance corporate greed and national interests. Without the first, we have no economy; without the latter, we have no country.

My advice to current and future IT workers? Lower your expectations, increase efficiency, update skills or move to some other field (such as plumbing). Eventually, offshore projects’ high rate of failure (actually higher than onshore development, in spite of CMM, Six Sigma and so on) and security threats will open CEO eyes. (CFOs will have to be shown how the promised 80 percent of savings turned into paltry 5 percent in reality.) Low IT enrollment will bring down the price of education, and when foreign lawyers and doctors are allowed to practice in U.S., the only safe haven remaining will be the profession of politician.

Alex Kriegel
Senior Programmer/Analyst
Pope & Talbot
Portland, Ore.

QUALITY WORK, FAIR PRICE

I applaud the space Software Development has devoted to the impact of globalization on IT, but I must be living on a different planet than reader Julie Crego (“Race to the Bottom,” Feedback, Nov. 2005), with respect to her worries about IT wages and cost of living and product quality.

I personally have benefited from the vastly overpriced cost of IT labor, but in a market economy, supply and demand, not recent local history, determine prices. The alternative to a market economy was catastrophically rejected in a number of countries where it was given a fair trial for more than half a century. More importantly, the worldwide demand for technology skills persists, and will for the foreseeable future continue to rise rapidly, despite a local dot-bomb speed bump and a recent marked increase in overseas supply. The market is self-correcting, and the dot-bomb has constricted the flow of new graduates in tech fields, so IT wages must necessarily rise again, as they must long-term anyway.

On my planet, just about everything I buy has a lower real cost than it did 20 years ago. Middle- and low-income people now regularly purchase vast quantities of nonessentials (a.k.a. luxuries) that the previous generation simply could not afford. The U.S. population continues to rise, despite a birth rate no higher than every other technically advanced nation in the world, all of whom are suffering decline. It is not merely Mark Wesker’s personal opinion that people like what they can afford here (“Offshoring Works,” Offshore Forum, Sept. 2005).

Yes, product quality is down all over, as much or more for non-tech products produced here by U.S. citizens as for outsourced IT products, obviously therefore not a direct consequence of outsourcing. I suspect the biggest contributing factor is the better communication brought on by that high-tech U.S. invention, the Internet.

Outsourcing is not a new problem (doesn’t anybody remember the “giant sucking sound”?), but the market economy is self-correcting. I told my computer science students that people who deliver quality work at a fair price will find employers willing to pay for it; those who overprice their labor or underdeliver won’t. That’s not a hard concept to understand.

Tom Pittman
Bolivar, Mo.

MORE HOGWASH

Regarding Mark Wesker’s response to Julie Crego’s letter, published in Feedback (“Race to the Bottom,” Nov. 2005): You are editors of a journal that is devoted to “actually making something work”: Here’s how to do it—correctly—use footnotes and references and standards.

You had a responsibility to provide Mr. Wesker a sampling of replies to his article. He should know from those replies what is important to your readers. You did not. You failed in your responsibility to me, your reader.

Mr. Wesker was given carte blanche to continue his emotional tract. And in 13 column inches, he cites exactly zero verifiable facts.

I thought I could trust Software Development to have screened out, as Mr. Helvey says, the “hogwash.”

Michael Houston
President
MicroDesign Specialists
Burbank, Calif.

The editors respond:
Mr. Wesker was sent every letter we received in response to his article “Offshoring Works” (Offshore Forum, Sept. 2005)—which, incidentally, was a counterpoint to Ron Hira’s anti-offshoring article “Eroding Opportunities” in the same issue. We were also disappointed in the lack of specifics in Mr. Wesker’s response, but chose to print it, so that our readers could judge the quality of his comments for themselves.

DISPOSE OF DIGNITY

Donna Davis’s article “Are You a Promotable Developer?” ( Career Center, Nov. 2005) reinforced what I have always believed: It’s not the people who do the best work who get promoted. It’s the people who toot their own horn and suck up the most. I guess those of us who have a shred of dignity will never get promoted.

Name withheld

Donna Davis responds:
I agree that no one wants an arrogant, self-promoting CIO-wannabe as a coworker (or employee, for that matter). However, as a supervisor, it’s frustrating to ask an employee to provide an update of accomplishments for a performance review and receive a sentence that could be paraphrased as “nothing much,” simply because he or she is modest. Knowing the employee to be a hard worker, I’m compelled to justify, embellish and fill in the holes myself. That’s the supervisor’s job, you might say, but when you supervise 10 or more developers, it’s difficult and time-consuming. No one has a greater interest in your next promotion than you, so it’s up to you to represent yourself well. That’s not the same as “sucking up,” and almost all supervisors can tell the difference.

ENDING ANTAGONISM

Bran Selic’s stance on the conservatism of programmers when it comes to modeling (“The Coding Conservatives,” Deadline, Oct. 2005) is certainly bound to induce many reactions from Software Development’s readers.

Though it’s true that programmers’ tendency to get “infatuated with the technology” might reduce their inclination to model, other factors independent from the programmers themselves are worth mentioning: First, traditional project management separates programming and modeling roles and assigns them to different people, a situation that has been institutionalized in career paths and rate grids. Second, the bottom line that’s often critical for small companies gives modeling a superfluous taste to management. Third, the academic atmosphere that surrounds initiatives like MDA makes the whole approach look everything but pragmatic.

Finally, the traditional “database diktat” still drives many projects to model their data first into vendor-specific tools.

But there are signs of hope that programmers, after getting “test infected,” will become “model infected.” The border between the apparently opposed worlds of modeling and coding shows some signs of porosity in both directions. For example, when chatting at whiteboards, programmers now naturally use UML notations to express their ideas.

Also, on midsize projects, it’s now common practice to reverse-engineer an application to a UML model to perform some analysis and reorganization (such as package coupling reduction). Furthermore, big projects or organizations opting for MDA assign extremely skilled coders to their architectural teams to guarantee that the generated code will be as good as that written by an expert coder.

When this porosity gives way to osmosis, the antagonism between coding and modeling will be history.

David Dossot

Vice President of
Technology/Founder
Agile Partner SA
Thionville, France

THANK YOU, NASA

Regarding Alexandra Weber Morales’s Oct. 2005 editorial “Watching Space”: As my father was one of those “rocket scientists” of NACA/NASA fame who helped build the Glenn (Lewis) Research Center and design the booster thrush cones that didn’t melt down, I have this to add:

First, rocket science put me through school at Case Western Reserve University (a.k.a. Case Institute of Technology).

As my father was in the position to learn and use computers when they first stuck their heads above the pages of mathematical tables, rocket science also got me programming for my junior high science fair project (an algebraic manipulator).

As one of the charters of NASA was to do applied-basic research that would be shared by all related industries, rocket science also helped create safer, more efficient airplanes to fly me around the world as I began my own career writing and installing software for communications systems.

On a related note, do we say that we don’t need the Department of Defense? It provided me with projects to work on in graduate school, creating the first generations of distributed graphics and computer-aided logic design systems, and it provided me with the Internet that I use today to live in Seattle and work in Cleveland without having to physically commute.

None of this means that I support the terrorism directed toward the poor and working here and around the world. But, as in everything, there is a piece of the truth. Let us proceed, with moderation in all things, to create an ever-advancing civilization.

Donald Huff
Software Architect
MCR
Seattle, Wash.

I’D RATHER BE A DENTIST

I enjoyed Warren Keuffel’s article on the decline in computer science majors in the U.S. (“Decline and Fall,” Interface, Aug. 2005). I graduated with a computer science and engineering degree in 1994 and experienced firsthand what I believe drives many from hands-on software development and keeps others from entering the field.

First, the return on investment for programmers is low. As a student, I spent 18-21 hours a week in class, another 12-16 hours a week on homework and another 30-60 hours in the lab. The course load caused me to take an extra couple of quarters to graduate. Contrast that with my accounting major roommate who graduated in four years, spending comparable time in the classroom and on homework. After five years in the market, we earned the same salary. After 10, he makes more than I do, and his job is much less likely to be outsourced.

Second, being a great programmer gives you the burden of carrying your weaker colleagues. Frustration at shouldering an ever-larger share of responsibility, with no recognition or increased compensation, led me to change my career focus to architecture.

Third, many companies define very poor career paths for their developers—if you’re good at what you do, you run a high risk of being pigeonholed.
Finally, it’s difficult to tell the difference between a great, good or bad developer. In my first job out of college, I was paired with an electrical engineer who couldn’t write code to save his life, yet after nine weeks of “training,” he was “on my level.” A funny result, considering that I wrote 100 percent of “our” code for the second product release, including rewriting and fixing what code he had contributed to the first.

I love writing software, but that joy is not enough. As long as companies seek cheap offshore coders, keep compensation in check, and worsen the problem by not showing kids the possible career path (a career path they can’t even explain to their staff), why would anyone want a computer science-based career? I started programming when I was nine, but if I had it to do all over again, I’d be a dentist.

Name withheld

Warren Keuffel responds:
You make some excellent points about the return on investment. Not very many people think of careers in those terms—most people want to do what they love. But, as you point out, that may not be sufficient reason to enter a field.