Wednesday, May 05, 2004
Recently, on a list I belong to, a discussion occurred over what several posters perceived as CF programmers' diminished salaries and prospects. Here was my response:
The problem, as I see it, with the argument that "while technology changes, the theory behind programming hasn't changed" is that it *has* changed. And OO changed it. Twenty years ago, we could have an engaging debate about the future of OO v. procedural languages. That debate has been settled: OO emerged as the uncontested champion. But most CF developers that I meet and work with treat this sea change incorrectly (IMHO). They...
a. assume that OO is no big deal to pick up (a little syntax, a book or two here and there). Anyone can pick up the syntax of a new language (C#, Java, etc.) very quickly, but becoming a proficient OO programmer is a big change and it doesn't happen overnight.
b. waste energy in hoping/wishing/arguing/praying that the technology that they know and love will stage a comeback instead of taking up the big challenge to move with the tide.
c. are prone to the "Lake Wobegone" effect, where everyone is above average. This was OK while the dot com bubble kept inflating (everyone's salaries and prospects), but it's not sufficient now.
d. invest too much faith in a corporation to reverse the tides of change. What can Macromedia do about the trend towards diminshed salaries and prospects for CF programmers? Honestly, nothing.
What's required of us, I believe, is finding the courage to face a brave, new world in which we are immigrants and strangers. For the great majority of programmers, this means that we need to strategically plan for a world in which OO competence (not just superficial knowledge) is key to survival. This is really hard, I know, but the consequences of inaction will be, I believe, very severe.
The problem, as I see it, with the argument that "while technology changes, the theory behind programming hasn't changed" is that it *has* changed. And OO changed it. Twenty years ago, we could have an engaging debate about the future of OO v. procedural languages. That debate has been settled: OO emerged as the uncontested champion. But most CF developers that I meet and work with treat this sea change incorrectly (IMHO). They...
a. assume that OO is no big deal to pick up (a little syntax, a book or two here and there). Anyone can pick up the syntax of a new language (C#, Java, etc.) very quickly, but becoming a proficient OO programmer is a big change and it doesn't happen overnight.
b. waste energy in hoping/wishing/arguing/praying that the technology that they know and love will stage a comeback instead of taking up the big challenge to move with the tide.
c. are prone to the "Lake Wobegone" effect, where everyone is above average. This was OK while the dot com bubble kept inflating (everyone's salaries and prospects), but it's not sufficient now.
d. invest too much faith in a corporation to reverse the tides of change. What can Macromedia do about the trend towards diminshed salaries and prospects for CF programmers? Honestly, nothing.
What's required of us, I believe, is finding the courage to face a brave, new world in which we are immigrants and strangers. For the great majority of programmers, this means that we need to strategically plan for a world in which OO competence (not just superficial knowledge) is key to survival. This is really hard, I know, but the consequences of inaction will be, I believe, very severe.
Friday, April 02, 2004
I'm disappointed. I thought that Flex might be a way for Macromedia to change the terms of the debate -- the debate being between .NET and Java. But with the pricing scheme for Flex, I think the current debate will continue: Sparkle on the .NET side and Java Server Faces on the Java side.
When Spectra was first being discussed, I said at the time that I thought Allaire/Macromedia just didn't understand their market. Presumptuous of me, I know, but I stand by it still. Everyone wants to get into the enterprise space, which I guess explains the very, very high pricing on Flex, but I think Flex will have a small and slow adoption rate. The problem is that they are squandering the little, precious time they have in being out front on this. So, if in 6 months, they reduce the price to something reasonable, that may very well be too little, too late. Let's hope they prove me wrong.
When Spectra was first being discussed, I said at the time that I thought Allaire/Macromedia just didn't understand their market. Presumptuous of me, I know, but I stand by it still. Everyone wants to get into the enterprise space, which I guess explains the very, very high pricing on Flex, but I think Flex will have a small and slow adoption rate. The problem is that they are squandering the little, precious time they have in being out front on this. So, if in 6 months, they reduce the price to something reasonable, that may very well be too little, too late. Let's hope they prove me wrong.
Wednesday, March 24, 2004
Some thoughts on the role of teaching and the teacher.
In good teaching, the teacher puts the student in distress. That is, the teacher deliberately, consciously, and (hopefully) skillfully asks the student to do things that are outside the student's comfort zone and may be outside their present abilities. Students do not like this; none of us like being placed in a situation where our embarassment and inability may be shown so clearly.
There are two ways to relieve the student of their distress. The first (all-too-common) way is to structure the training so that situations like this seldom if ever arise. We see this in the highly scripted training materials (and instructors!) where the student is led from one exercise to another to another. This can work, because if you just follow the printed/oral instructions, you won't risk failure. Two and a half days of this mind-numbing stuff and you can get a certificate to hang on your wall.
The other way to relieve the student of their distress is to expand their present abilities/mindset, so that what looked hard or impossible now seems natural and pleasant. In fact, it's more than pleasant: students who get this kind of relief feel tremendously empowered and they get excited. Clearly, this is the better path, so why don't we see more of it?
First, it requires the teacher to put him/herself in distress. If my job as teacher is to read slides, hand out materials, and answer occasional questions, my task is pretty easy[1]. That is, there's little occasion for distress. But the other route -- that's far more dangerous. I'm going to be intentionally placing myself in a situation where, if you don't "come through" the experience, you won't think much of me. You may get mad. You may call my boss and complain. It's no wonder that this is the path less travelled.
So, if one method of teaching involves distress for both student and teacher and the other way minimizes or eliminates stress, why should we choose the riskier path? In my experience of teaching, students would dearly love for me to provide answers to all the questions I ask them -- before they even try to answer themselves! Then, they will dutifully write it down. So what's wrong with this?
The good teacher knows that they have a very small amount of time with the student and that when the student returns to the "real world", he must be able to arrive at the answers for himself. The role of the teacher is to help facilitate a transformation so that the student acquires deep knowledge. Shallow knowledge is easy and we see far too much of it. In shallow knowledge, the student learns magic incantations. They write these words, push this button, and the desired result happens. The rote behavior masks a lack of deep knowledge.
But shallow knowledge will not ultimately be helpful. The good teacher knows this and she resists both her and her student's inclination to avoid feelings of distress. She wants her students to gain insights so that they can solve their own problems and so she pulls, prods, encourages, remands--in short, she does whatever she can to help her students arrive at that "Aha!" moment where the knowledge -- the deep knowledge -- that seemed so utterly impossible to attain belongs to the student forever.
[1] There's a joke associated with this remark. It seems that a university Physics professor made a great breakthrough and had agreed to do a series of talks at universities throughout the country detailing his discoveries. Because the professor disliked airplanes, he hired a chaffeur to drive him from one spot to the next. Spending so much time together, the professor and the chaffeur became friendly and in the course of time, the chaffeur confided that he thought the professor had about the easiest job in the world.
"How's that?" asked the professor.
"Well," said the driver. "You give the same talk night after night. You get asked the same questions night after night. There's just nothing to it. Really, I've heard it so many times now, even I could do it."
At this, the professor challenged the chaffeur and at their next stop, the chaffeur and the professor changed roles (and clothes). Good as his word, the chaffeur gave a very successful talk and, just as he had predicted, the same questions were asked. That is, until one person asked a new question, one the chaffeur-cum-professor didn't know. He thought about it for a while and finally said, "Young man, that is the single most stupid question I have EVER been asked. Why, I'm surprised that you don't know the answer to it. I would think anyone would. In fact, the question is so simple, I'm going to have my chaffeur answer it!"
In good teaching, the teacher puts the student in distress. That is, the teacher deliberately, consciously, and (hopefully) skillfully asks the student to do things that are outside the student's comfort zone and may be outside their present abilities. Students do not like this; none of us like being placed in a situation where our embarassment and inability may be shown so clearly.
There are two ways to relieve the student of their distress. The first (all-too-common) way is to structure the training so that situations like this seldom if ever arise. We see this in the highly scripted training materials (and instructors!) where the student is led from one exercise to another to another. This can work, because if you just follow the printed/oral instructions, you won't risk failure. Two and a half days of this mind-numbing stuff and you can get a certificate to hang on your wall.
The other way to relieve the student of their distress is to expand their present abilities/mindset, so that what looked hard or impossible now seems natural and pleasant. In fact, it's more than pleasant: students who get this kind of relief feel tremendously empowered and they get excited. Clearly, this is the better path, so why don't we see more of it?
First, it requires the teacher to put him/herself in distress. If my job as teacher is to read slides, hand out materials, and answer occasional questions, my task is pretty easy[1]. That is, there's little occasion for distress. But the other route -- that's far more dangerous. I'm going to be intentionally placing myself in a situation where, if you don't "come through" the experience, you won't think much of me. You may get mad. You may call my boss and complain. It's no wonder that this is the path less travelled.
So, if one method of teaching involves distress for both student and teacher and the other way minimizes or eliminates stress, why should we choose the riskier path? In my experience of teaching, students would dearly love for me to provide answers to all the questions I ask them -- before they even try to answer themselves! Then, they will dutifully write it down. So what's wrong with this?
The good teacher knows that they have a very small amount of time with the student and that when the student returns to the "real world", he must be able to arrive at the answers for himself. The role of the teacher is to help facilitate a transformation so that the student acquires deep knowledge. Shallow knowledge is easy and we see far too much of it. In shallow knowledge, the student learns magic incantations. They write these words, push this button, and the desired result happens. The rote behavior masks a lack of deep knowledge.
But shallow knowledge will not ultimately be helpful. The good teacher knows this and she resists both her and her student's inclination to avoid feelings of distress. She wants her students to gain insights so that they can solve their own problems and so she pulls, prods, encourages, remands--in short, she does whatever she can to help her students arrive at that "Aha!" moment where the knowledge -- the deep knowledge -- that seemed so utterly impossible to attain belongs to the student forever.
[1] There's a joke associated with this remark. It seems that a university Physics professor made a great breakthrough and had agreed to do a series of talks at universities throughout the country detailing his discoveries. Because the professor disliked airplanes, he hired a chaffeur to drive him from one spot to the next. Spending so much time together, the professor and the chaffeur became friendly and in the course of time, the chaffeur confided that he thought the professor had about the easiest job in the world.
"How's that?" asked the professor.
"Well," said the driver. "You give the same talk night after night. You get asked the same questions night after night. There's just nothing to it. Really, I've heard it so many times now, even I could do it."
At this, the professor challenged the chaffeur and at their next stop, the chaffeur and the professor changed roles (and clothes). Good as his word, the chaffeur gave a very successful talk and, just as he had predicted, the same questions were asked. That is, until one person asked a new question, one the chaffeur-cum-professor didn't know. He thought about it for a while and finally said, "Young man, that is the single most stupid question I have EVER been asked. Why, I'm surprised that you don't know the answer to it. I would think anyone would. In fact, the question is so simple, I'm going to have my chaffeur answer it!"
Saturday, February 21, 2004
I recently read an email inviting me to a CFUG where a "CF guru will show you the tricks of becoming a guru programmer." There's so much wrong with this idea that I hardly know where to start. First, expert programmers don't rely on "tricks". They rely on solid skills that lead to success. There's nothing particularly catchy about documentation, for example, but real programmers -- professional programmers -- know that code that isn't documented isn't done. And really expert programmers write their documentation before they write their code.
But that's not nearly as alluring a proposition as coming to hear a well-known speaker who promises instant success! The sad thing is that often these talks have the information content of a typical infomercial. Too often, they serve as nothing more than a forum for the "guru" to air his considerable ego while disempowering programmers.
A couple of years ago, I wrote an article entitled, "If you meet the Buddha on the road, kill him". The title wasn't mine; I borrowed it from an interesting book I read several years earlier. The idea behind it is that "gurus" are often a block to real understanding. Certainly someone promising to reveal "tricks" falls into that category, IMHO. The problem is that the guru provides non-specific advice such as "code it right and keep it tight" that offer no real guidelines for success. What is code that is "right" and "tight"? And is that all there is to project success? Tight code?
I really question the type of projects that some of these "gurus" have worked on. Were they ever charged with the responsibility for delivering a successful project? Did they ever have to build and work with a team? Were they responsible for the ongoing maintenance of the code? I don't see how such things could be if all they have learned from such experiences is silly mantras about tight code.
Fame, even fame in the small ColdFusion world, is a funny thing. You can become famous without offering anything of value. All that's required is a relentless will and a knack for self-promotion. Contrast this with the many, many programmers, both well-known and unknown, who provide a real contribution. Their main goal is not self-promotion, but the sharing of hard-won knowledge. I'm thinking of people like Ben Forta, Charlie Arehart, Ben Edwards, John Quarto, Brian Kotek, Ben Elmore, Simon Horwith, Steve Nelson, and the many, many, many others who work to help us all become better programmers.
So, I think I'll pass up the meeting with the guru and lose the chance to hear about "neat guru tricks". Instead, I think I'll read another chapter of a good book on programming such as "The Pragmatic Programmer" and learn something that can really help.
But that's not nearly as alluring a proposition as coming to hear a well-known speaker who promises instant success! The sad thing is that often these talks have the information content of a typical infomercial. Too often, they serve as nothing more than a forum for the "guru" to air his considerable ego while disempowering programmers.
A couple of years ago, I wrote an article entitled, "If you meet the Buddha on the road, kill him". The title wasn't mine; I borrowed it from an interesting book I read several years earlier. The idea behind it is that "gurus" are often a block to real understanding. Certainly someone promising to reveal "tricks" falls into that category, IMHO. The problem is that the guru provides non-specific advice such as "code it right and keep it tight" that offer no real guidelines for success. What is code that is "right" and "tight"? And is that all there is to project success? Tight code?
I really question the type of projects that some of these "gurus" have worked on. Were they ever charged with the responsibility for delivering a successful project? Did they ever have to build and work with a team? Were they responsible for the ongoing maintenance of the code? I don't see how such things could be if all they have learned from such experiences is silly mantras about tight code.
Fame, even fame in the small ColdFusion world, is a funny thing. You can become famous without offering anything of value. All that's required is a relentless will and a knack for self-promotion. Contrast this with the many, many programmers, both well-known and unknown, who provide a real contribution. Their main goal is not self-promotion, but the sharing of hard-won knowledge. I'm thinking of people like Ben Forta, Charlie Arehart, Ben Edwards, John Quarto, Brian Kotek, Ben Elmore, Simon Horwith, Steve Nelson, and the many, many, many others who work to help us all become better programmers.
So, I think I'll pass up the meeting with the guru and lose the chance to hear about "neat guru tricks". Instead, I think I'll read another chapter of a good book on programming such as "The Pragmatic Programmer" and learn something that can really help.
Wednesday, February 11, 2004
The CF-Talk list recently had a long thread of messages about the fact that Macromedia uses the Mach-II framework for some of its applications. A few people did not feel it was appropriate for Macromedia to be using any framework, as it presented a tacit endorsement of the framework.
Leaving that matter aside for now, I want to focus on what a couple of people said during the discussion. Their argument was that frameworks shouldn't be used at all -- or, a variation on the theme -- that real developers don't use frameworks. Finally, someone said that any standardized framework was flawed and that the only right way to do it was to create a customized framework for each application.
Reading these arguments, I thought, "Is it any wonder that we developers are held in such low esteem by business people -- the ones with checkbooks?" The rationale against frameworks was what it always is with such arguments -- that a totally customized framework can "outperform" standardized frameworks.
Well, if the real cost in software development was in achieving an additional 7% increase in performance, such arguments might have merit. But 70-90% of the lifetime cost of software is used in maintenance. There's a famous quote that says, "More computing sins are committed in the name of efficiency (usually without achieving it) than for any other reason -- including blind stupidity." Amen to that.
The problem with their argument against frameworks is that it "proves too much" as my old Logic professors used to say. Encapsulation and abstraction certainly take more time and require more code than hacking something out, but that cost is paid ONE TIME. The benefits of encapsulation and abstraction pay for themselves time and time again.
That's true with frameworks (at least well-designed frameworks) as well. It took a LOT of time to develop both Fusebox and Mach-II, but as someone who has developed very large applications with both, I can testify to the enormous amount of time, effort, and money that an application that uses a standardized framework can save.
But I know that no arguments will sway those who have an animus against *any* framework, however capable. The truly hopeful fact is that such fatuous, specious arguments fall flat in the face of people who are accountable for having flexible, maintainable sites/applications that don't break the bank. These arguments (all of which can be summarized by misquoting a famous line: "framework? we don't need no stinkin' framework") might have succeeded during the heady days of the dot-com bubble. But the fact is that companies do care about costs -- both maintenance costs and training costs. So while a few legends-in-their-own-minds want to argue that they are such excellent programmers that they don't need a framework, really excellent programmers realize that frameworks remove a lot of the grunt code so that they can concentrate on providing clients with what they really want.
Leaving that matter aside for now, I want to focus on what a couple of people said during the discussion. Their argument was that frameworks shouldn't be used at all -- or, a variation on the theme -- that real developers don't use frameworks. Finally, someone said that any standardized framework was flawed and that the only right way to do it was to create a customized framework for each application.
Reading these arguments, I thought, "Is it any wonder that we developers are held in such low esteem by business people -- the ones with checkbooks?" The rationale against frameworks was what it always is with such arguments -- that a totally customized framework can "outperform" standardized frameworks.
Well, if the real cost in software development was in achieving an additional 7% increase in performance, such arguments might have merit. But 70-90% of the lifetime cost of software is used in maintenance. There's a famous quote that says, "More computing sins are committed in the name of efficiency (usually without achieving it) than for any other reason -- including blind stupidity." Amen to that.
The problem with their argument against frameworks is that it "proves too much" as my old Logic professors used to say. Encapsulation and abstraction certainly take more time and require more code than hacking something out, but that cost is paid ONE TIME. The benefits of encapsulation and abstraction pay for themselves time and time again.
That's true with frameworks (at least well-designed frameworks) as well. It took a LOT of time to develop both Fusebox and Mach-II, but as someone who has developed very large applications with both, I can testify to the enormous amount of time, effort, and money that an application that uses a standardized framework can save.
But I know that no arguments will sway those who have an animus against *any* framework, however capable. The truly hopeful fact is that such fatuous, specious arguments fall flat in the face of people who are accountable for having flexible, maintainable sites/applications that don't break the bank. These arguments (all of which can be summarized by misquoting a famous line: "framework? we don't need no stinkin' framework") might have succeeded during the heady days of the dot-com bubble. But the fact is that companies do care about costs -- both maintenance costs and training costs. So while a few legends-in-their-own-minds want to argue that they are such excellent programmers that they don't need a framework, really excellent programmers realize that frameworks remove a lot of the grunt code so that they can concentrate on providing clients with what they really want.
Tuesday, January 27, 2004
The code I showed for the issue with arrays being passed by value and not reference is faulty. To see the problem, you'd need to have this:
For a fuller explanation of the problem, check out the CF Quiz in the Newletters section of halhelms.com
<cffunction name="addMember">
<cfargument name="member" />
<cfset var team = getTeam() />
<cfset ArrayAppend(team, arguments.member) />
</cffunction>
For a fuller explanation of the problem, check out the CF Quiz in the Newletters section of halhelms.com
Thursday, January 15, 2004
I've been traveling a lot recently. Right now, I'm in lovely (as in warm) Tampa. Last week, I was at Macromedia in San Francisco with Ben Edwards working with a group of their developers on Mach-II. (You can read about the experience from their side at www.corfield.org/blog.)
While I was in San Francisco, the issue of how CF works with arrays came up. Let me set up the problem for you. Here's part of the CFC...
Seems like that should work, right? But because CF copies arrays (instead of passing a reference to them), it doesn't. I started thinking how nice it would be if we had the kind of ability to handle collections of things that Java has. When I got home Sunday night from SF, I had an email from my editor at CFDJ that my article was due on the previous Friday. Errr...no time like the present for seeing if I could put something together to solve the array problem and my overdue article problem.
If you're not familiar with Java's collection classes, they're pretty nice. Very handy and very easy to use. Need to add an element to an array-like class (ArrayList)? Just use the add method. To loop over an ArrayList, you ask the object for an iterator that has methods like hasNext (returning a boolean) and next (returning the element).
Anyway, I found it very easy to implement an ArrayList and Iterator CFC and will add the code to my site when I swoop back into Atlanta for 6 hours over the coming weekend.
While I was in San Francisco, the issue of how CF works with arrays came up. Let me set up the problem for you. Here's part of the CFC...
<cfcomponent...>
<cfset variables.team = ArrayNew(1) />
<cffunction name="getTeam" returntype="array">
<cfreturn variables.team />
</cffunction>
<cffunction name="addMember">
<cfargument name="member" />
<cfset ArrayAppend(getTeam(), arguments.member) />
</cffunction>
</cfcomponent>
Seems like that should work, right? But because CF copies arrays (instead of passing a reference to them), it doesn't. I started thinking how nice it would be if we had the kind of ability to handle collections of things that Java has. When I got home Sunday night from SF, I had an email from my editor at CFDJ that my article was due on the previous Friday. Errr...no time like the present for seeing if I could put something together to solve the array problem and my overdue article problem.
If you're not familiar with Java's collection classes, they're pretty nice. Very handy and very easy to use. Need to add an element to an array-like class (ArrayList)? Just use the add method. To loop over an ArrayList, you ask the object for an iterator that has methods like hasNext (returning a boolean) and next (returning the element).
Anyway, I found it very easy to implement an ArrayList and Iterator CFC and will add the code to my site when I swoop back into Atlanta for 6 hours over the coming weekend.
