CFUN-03 Sunday Keynote

by Hal Helms

When I was a boy--and remember this was just after dirt was invented--I had a childhood hero, a baseball player: Mickey Mantle. Mickey Mantle was one of the greatest hitters of all time. He hit a total of 536 home runs, had a lifetime batting average of .298, and batted in over 1500 runs. For those of you not versed in baseball statistics, let me just say that those are good statistics.

Now, Alex Rodriguez is a modern-day player with good statistics, also. A couple of years ago, Rodriguez shocked the baseball world by signing a contract for a quarter of a billion dollars. Mickey? The most he ever made in a season was $100,000-and that was considered enormous.

So why the discrepancy? And such a huge discrepancy? One idea profferred is that things are just wacky-that no one is worth that kind of money. Well, maybe. But another idea, one I find both more intriguing and more accurate, is that the market for baseball players has only recently become anything like efficient. An efficient market is one that fairly values an asset. It was Mickey's poor luck to live in a time where the market for great baseball players was inefficient.

What, if anything, does this tell us about our situation? I'd like to propose the idea that today, programmers are both grossly underpaid and grossly overpaid-that the market for programmers is very inefficient. That idea that programmers are both under- and overpaid is crazy enough that it needs some explanation if I am to have any chance to convince you that it just might be true-and that the truth of this statement might be very important to you. So let me try by telling you a story.

About three years ago, I was asked to act as architect and chief programmer on the Rooms To Go ecommerce site, roomstogo.com. I spent some seven months working on the site for the largest furniture retailer in the United States. They were terrific people to work with and we had a lot of fun, but that's a different story.

As we got within a month of the site deploying, which would be coordinated with a major ad campaign, I received a phone call from a friend of mine in Boston. Dave was bursting with excitement. He had just signed a contract with a very large corporation to do an ecommerce site and was calling to tell me all about it. After hearing about the scope of the project (large), I became curious about the contract amount: how much was he getting for this big project? "$30,000," he told me proudly.

"You mean $300,000?" I asked. But no, it was $30,000. I asked Dave how long he had to do the job. "One month," he stated. I was horrified. How could anyone succeed given those parameters? "Wow, Dave, that's...a challenge. What are you going to do?" I asked him.

Matter-of-factly, Dave rejoined, "Why, that's why I'm calling you!"

If you've ever had a friend show up at your doorstep at midnight-drunk-you can imagine the position I was in. I had to help Dave, but knew the odds for success were tiny. We used both Fusebox and the Fusebox Lifecycle Process (FLiP) and-to my utter astonishment-succeeded: the project was done on budget and on time.

Now, the full story of this project would make a great book, I'm convinced, but the important point of it for our purposes is we used a ColdFusion shop in the Philippines to do the actual coding. Those of you familiar with FLiP know that it relies on coders following Fusedoc, a documentation and program definition language.

The Filipino coders, who did an excellent job, were college-educated, English-speaking, professional programmers. And what did they make for their work? $1.80 an hour. Now, I'm guessing that that sort of money doesn't excite you? No? Me neither. But is your code-or mine-orders of magnitude better, as the difference in price per line of code would indicate? Well, I worked with their code and I can tell you that it isn't. So why are we paid so much more?

I think the answer has to be that we have an inefficient market for code. Now, the bad news is that markets, over time, tend to become efficient. The bad news that I have to deliver today is that you're being grossly overpaid. Gee--aren't you glad you got up early to hear this inspiring message?

Now, don't leave quite yet, because there's a silver lining in this cloud, but I first want to ask you a question. What business are you in? Does that seem like a foolish question? Isn't the answer obvious? We're in the business in coding, right? Well, not so fast, Sparky. If that's your answer, you've just placed yourself in competition with $1.80/hr coders. And if that's not bad enough news, consider that the ability to write code is a wasting asset. If you had today only the knowledge you had five years ago, do you think you'd like your prospects? I know I wouldn't. So, if you're job is writing code-well, the word, "bleak", comes to mind.

But wait! I promised there was some good news! The good news is that you get to define what your job is. You can say it's coding-but that doesn't look too promising. What other answers can we come up? Well, let me tell you a statistic that I use quite often: the success rate for custom, corporate software is, as of 2002, 28%. And that was an improvement over 2001! Coding may be overpriced, but people who can provide successful software solutions are grossly underpaid. And the good news is that markets, over time, tend to become efficient.

So, how do we go about providing successful software solutions? Ah, there's the rub-as Bill Shakespeare noted some centuries ago. Because the cruel law of evolution-what so many people find profoundly disturbing about evolution-is that what's good today may not be good tomorrow-at least not good enough.

Dinosaurs ruled the earth for 150 million years, but they weren't able to adapt to the change of climate occasioned by a great asteroid strike. Those little, furry critters (a long time later we would call them mammals) that could adapt themselves managed to survive. The descendants of those furry but adaptive creatures are us--you and me.

Well, now I'm really ranging far afield, so let me try to bring this back to you and me today. And we-both as a species and as individual people-have thrived by our ability to adapt. That adaptability thing is a pretty successful strategy. Humans have the ability to adapt primarily by using our brains. That's where you and I come in. Using our brains.

Today, we're in the midst of a revolution in software engineering and that revolution is object oriented programming. Well, that statement isn't entirely true. No, it would be more accurate to say that the revolution is nigh over-and we risk being left behind, perhaps like the dinsaurs unaware of our fate.

This revolution is not a political one, but a technological one. The revolution is one in which the tools of a past age-procedural design and coding-are being replaced by the tools of a new one-object oriented. If you stack up the object oriented languages on one side of the scale and the procedural languages on the other, there's really no contest. On the OO side, we have Java, C#, Smalltalk, Ruby, Eiffel, C++, PHP, Python--the list is long. Even COBOL has gone OO. On the procedural side, we have...uh...C, Fortran, and ColdFusion?

Ah, but we have CFCs now. So, we're set, right? Again, not so fast, Sparky. Let's leave aside the question of whether CFCs really implement object orientation. For the sake of this discussion, let's concede that they implement it fully. Where does that get us?

Well, some people say that we just need to read the Gang of Four's Design Patterns. So, we hear about various design patterns and are urged to "use them". Well, that's not very helpful advice. What's a design pattern? For that matter, what's an object?

The sad truth is that design patterns have suffered a terrible fate: they have become buzzwords. And buzzwords have the awful power of turning off those marvelous adaptive brains that took so long to develop. And that is a true tragedy. Our ability to thrive-even to survive-relies on our ability to gain true understanding. Buzzwords won't help us; we need knowledge.

Even this weekend, I've head buzzwords bandied about as though they were magic-as though invoking them would somehow convey power to the listeners. The power to develop successful software doesn't come from learning terms, but from understanding the real meaning behind them-from attaining our own understanding of the wisdom they offer. Buzzwords are, after all, just words.

If we acquire real knowledge of object orientation-and that requires a deep and fundamental shift in the way that we think-we have enormous power in our hands. If we're not mere coders, what are we? We are developers; our job is to develop successful software solutions. As such, we have great power. Our work has enormous leverage on world economies. With such stakes, it pays to go beyond buzzwords.

Or does it? Pay, I mean? Well, it doesn't pay as well as it should. And, my opinion is that it doesn't pay as well as it will. I have great faith in markets ability to self-correct, to become more efficient. The real question is which side of the market are we on? Are we mere coders? Or are we developers? Because how we come down on that question matters a great deal to each of us when markets do self-correct.

Many of us became accidental programmers. Now, I certainy find no shame in this. I began my own checkered career as a mason, then became a carpenter, and later a woodworker. At different points in my life, I have worked as a marketing director, an exterminator, a salesman, and a musician.

But today I am, as most of you are, a developer. And I take that responsibility very seriously, as I'm sure you do, too. If we agree that our job is to successfully deploy software applications--well, how do we do that? What is a successful software application?

Years ago, Henry Ford laid down the conventional wisdom of a successful product: customers can have any color they want, as long as it's black. That was an era when a successful product mainly meant building and delivering the product. Over time, our opinion of what success meant shifted. The meaning of a successful product meant that we gave customers what they want. But now, the new landscape of business means that the definition of success has shifted again.

As developers, our job is to build frameworks for change-frameworks that are so flexible that they can deal with the great constant of change. The question then becomes what are the best methods that we have developed for not only adapting to change, but actively cooperating with it? In software, the most successful method we have arrived at is the use of object-oriented designs, with those designs implemented in object-oriented languages.

As I said, it is a profound change, a revolution in software engineering. Revolutions don't come easy. They're times of great change. And they make great requirements on people who live during times of revolution. That would be us. The worst thing that we can do is to cling to the past-however comfortable and secure it is and however frightening and uncertain the future may seem. As the poet, Andre Gide said, "One does not discover new lands without consenting to lose sight of the shore for a very long time."

What are those requirements on us? Now, we must leave the world of "big ideas" and deal with the messier world of implementing those big ideas. Only actions can create the successes that our customers--and we--want. What are those actions?

We need to make a commitment to learning object orientation. This is not to be done by reading "Learn OO in 21 Days". So what do we do? Well, how do you eat an elephant? One bite at a time.

You might start by reading a book on basic object orientation. And no, I'm not talking about the Gang of Four's Design Patterns. Design Patterns is an excellent book, filled with rich wisdom, but it relies absolutely on a thorough theoretical and practical understanding of object orientation. But you might try a small book by David Taylor called Object Technology: A Manager's Guide. At 220 pages or so, it will provide you with a good basis for what object orientation is all about.

You could move on to Eben Hewitt's excellent Java for ColdFusion Developers book. Or, if you want a real jumpstart to your Java knowledge, I don't know any better method than taking an instructor-led class. And it seems to me I have heard about one class in particular...(http://halhelms.com/index.cfm?fuseaction=training.javaDetails)

Evolution--the gradual weeding out of those lest adaptable--is not something confined either to history or to species alone. Today, we are in the position of being able to consciously evolve by improving our understanding, by grasping the revolution that has already succeeded.

Robert Browning observed, "A man's reach should exceed his grasp-else what's a Heaven for?" How long will this journey take? The answer to that question isn't really important. It's not a matter of speed; it's a matter of getting started.