Here is a good piece on instructional design:
http://educationnew.arts.unsw.edu.au/staff/sweller/clt
Wednesday, April 4, 2007
criticism of PowerPoint
This comes from wikipedia:
One major source of criticism of PowerPoint comes from Yale professor of statistics and graphic design Edward Tufte, who criticizes many emergent properties of the software:
Its use to guide and reassure a presenter, rather than to enlighten the audience;
Unhelpfully simplistic tables and charts, resulting from the low resolution of computer displays;
The outliner causing ideas to be arranged in an unnecessarily deep hierarchy, itself subverted by the need to restate the hierarchy on each slide;
Enforcement of the audience's linear progression through that hierarchy (whereas with handouts, readers could browse and relate items at their leisure);
Poor typography and chart layout, from presenters who are poor designers and who use poorly designed templates and default settings;
Simplistic thinking, from ideas being squashed into bulleted lists, and stories with beginning, middle, and end being turned into a collection of disparate, loosely disguised points. This may present a kind of image of objectivity and neutrality that people associate with science, technology, and "bullet points".
Tufte's criticism of the use of PowerPoint has extended to its use by NASA engineers in the events leading to the Columbia disaster. Tufte's analysis of a representative NASA PowerPoint slide is included in a full page sidebar entitled "Engineering by Viewgraphs" in Volume 1 of the Columbia Accident Investigation Board's report.
Critics of the prewar planning by the U.S. Department of Defense prior to the invasion of Iraq in 2003 also point to a reliance on PowerPoint presentations as a poor alternative to traditional military briefing methods. A report issued by The National Security Archive at George Washington University in February 2007 released declassified PowerPoint slides relating to prewar assumptions and also criticized the reliance on PowerPoint itself as a presentation medium. The report included quotes from two senior officers regarding PowerPoint:
Lt. Gen. McKiernan later told Washington Post reporter Thomas E. Ricks (Fiasco, p. 75):
"It's quite frustrating the way this works, but the way we do things nowadays is combatant commanders brief their products in PowerPoint up in Washington to OSD and Secretary of Defense... In lieu of an order, or a frag [fragmentary] order, or plan, you get a set of PowerPoint slides... [T]hat is frustrating, because nobody wants to plan against PowerPoint slides."
Retired Army Col. Andrew Bacevich told Ricks (Fiasco, pp. 75-76) that PowerPoint war planning was the ultimate insult:
"Here may be the clearest manifestation of OSD's [Office of Secretary of Defense] contempt for the accumulated wisdom of the military profession and of the assumption among forward thinkers that technology -- above all information technology -- has rendered obsolete the conventions traditionally governing the preparation and conduct of war. To imagine that PowerPoint slides can substitute for such means is really the height of recklessness."
One major source of criticism of PowerPoint comes from Yale professor of statistics and graphic design Edward Tufte, who criticizes many emergent properties of the software:
Its use to guide and reassure a presenter, rather than to enlighten the audience;
Unhelpfully simplistic tables and charts, resulting from the low resolution of computer displays;
The outliner causing ideas to be arranged in an unnecessarily deep hierarchy, itself subverted by the need to restate the hierarchy on each slide;
Enforcement of the audience's linear progression through that hierarchy (whereas with handouts, readers could browse and relate items at their leisure);
Poor typography and chart layout, from presenters who are poor designers and who use poorly designed templates and default settings;
Simplistic thinking, from ideas being squashed into bulleted lists, and stories with beginning, middle, and end being turned into a collection of disparate, loosely disguised points. This may present a kind of image of objectivity and neutrality that people associate with science, technology, and "bullet points".
Tufte's criticism of the use of PowerPoint has extended to its use by NASA engineers in the events leading to the Columbia disaster. Tufte's analysis of a representative NASA PowerPoint slide is included in a full page sidebar entitled "Engineering by Viewgraphs" in Volume 1 of the Columbia Accident Investigation Board's report.
Critics of the prewar planning by the U.S. Department of Defense prior to the invasion of Iraq in 2003 also point to a reliance on PowerPoint presentations as a poor alternative to traditional military briefing methods. A report issued by The National Security Archive at George Washington University in February 2007 released declassified PowerPoint slides relating to prewar assumptions and also criticized the reliance on PowerPoint itself as a presentation medium. The report included quotes from two senior officers regarding PowerPoint:
Lt. Gen. McKiernan later told Washington Post reporter Thomas E. Ricks (Fiasco, p. 75):
"It's quite frustrating the way this works, but the way we do things nowadays is combatant commanders brief their products in PowerPoint up in Washington to OSD and Secretary of Defense... In lieu of an order, or a frag [fragmentary] order, or plan, you get a set of PowerPoint slides... [T]hat is frustrating, because nobody wants to plan against PowerPoint slides."
Retired Army Col. Andrew Bacevich told Ricks (Fiasco, pp. 75-76) that PowerPoint war planning was the ultimate insult:
"Here may be the clearest manifestation of OSD's [Office of Secretary of Defense] contempt for the accumulated wisdom of the military profession and of the assumption among forward thinkers that technology -- above all information technology -- has rendered obsolete the conventions traditionally governing the preparation and conduct of war. To imagine that PowerPoint slides can substitute for such means is really the height of recklessness."
observation made during Pegasystems training
In a couple of my last posts I discussed the IT jobs that are moving to India. I am close to wrapping up two very intense weeks of training in this software produced by Pegasystems. Hence, I have spent the past 2 weeks in the area across the street from MIT in Cambridge MA, 5 miles from Boston. The observation is just that several (half) of the class is Indian, with some Asian mix. When I graduated from George Mason University (in 2000), out of the hundreds of people graduating with a technical masters of science degree, very few had last names I could pronounce (I mean something like 10 out of 1,000). I am just saying this because it suports some of what the author says in the book "My Job Moved to India and All I Got Was This Lousy Book". We Americans really cannot afford to be complacent.
Wednesday, March 21, 2007
software engineers = taxi drivers and vagrants?
I was in a Service Oriented Architecture class last week and the instructor told us that as he got out of a taxi the taxi driver looked up at the building and said "oh yeah, I remember that building. I programmed a lot of Fortran in that building". My instructor said that he was surprised to hear this coming from this guy. Yesterday, a coworker sent me a picture that he had said someone had taken. See below... Yes, one thing that is true of the IT profession is that one cannot let up on their laurels tooooo long -- or one risks becoming truly obsolete. IT changes soooo fast. Case in point, last week I was coming through the airport on a business trip. I had not one but two personal computers with me as I went through the security check. One being my "work" computer; the other being my truly "personal" computer. I laughed as I remembered my Dad and thought that he wouldn't believe it if he were alive (he died in 1987) that I routinely walked around with two computers that I carried in a little bag thrown over my shoulder. When he died, one of the loves of his life (besides my mom and me) was his rather large Sperry desktop computer. Believe me, one could not walk around the airport with this thing. ;-D
Tuesday, March 20, 2007
t-shirt about job moving to India and all they got was a lousy shirt
Apparently there are a lot of t-shirts being sold that says "My job just moved to India and all I got was this lousy shirt". (see next post about book with similar title) Apparently, Yamini Narayanan, an Indian-born 35-year-old with a Ph.D. in economics from the University of Oklahoma was interviewed by a newspaper reporter. After graduation, she had worked for a U.S. computer company in Virginia and had recently moved back to Bangalore with her husband to be closer to family. When she was asked how she felt about the outsourcing of jobs from her adopted country, America, to her native country, India, she responded with a revealing story: "I just read about a guy in America who lost his job to India and he made a T-shirt that said, `I lost my job to India and all I got was this [lousy] T-shirt.' And he made all kinds of money." Only in America, she said, shaking her head, would someone figure out how to profit from his own unemployment. And that, she insisted, was the reason America need not fear outsourcing to India: America is so much more innovative a place than any other country.
excerpt from "My Job Just Went to India (And All I Got Was This Lousy Book)"
Here is an excerpt from this excellent book:
I awoke to an odd smell. Where am I? I asked (aloud, I think). I was in Bangalore, India’s Garden City. That odd smell was the remarkably foreign combination of pollution, ultraspicy food from the hotel’s kitchen, and something else that I could never quite put my finger on. It was my first morning there, and I was late for work. I didn’t feel bad about that, considering the hellish 32-hour journey I had suffered to get there. And that my India-savvy co-worker tricked me into an all-night cultural immersion in the world’s scariest hotel, after getting off the plane in Bombay the night before. After coming to, I felt a panic, realizing that my driver must have been waiting downstairs for an hour. Oh God, he’ll be angry, I thought, as I scrambled to get ready for the first in a series of all-day interviewing sessions. That’s just what I need on my first morning in a place like this...an angry taxi driver. I rushed downstairs, resisting the fabulous aroma of a South Indian breakfast, and ran out to ask the doorman to page my driver. I asked if the driver had been there long. He had. Two hours. Ugh. I spent the first five minutes in the car with Joseph apologizing profusely over being late and making him wait. He laughed dismissively. This is my job. I wait all day. And as I found out later, he really did. He didn’t just drop me off at work and come back at a fixed time. He waited at the office until the very minute I was ready to go. Without warning, at any time, I could come down from the office and expect to hop into the car and be driven away.
My first exposure to India in daylight was that drive across town from the northwestern corner of Bangalore to the southwestern corner. The culture shock started to hit me. Bangalore is known as India’s Silicon Valley. Being from a small city back home, it was exciting to realize that I had come to a technical mecca. More surprising, though, were the extreme contrasts between high tech and low tech. I saw half-naked children playing in the dirt in front of a huge Yahoo! sign. I saw a rickshaw with a Novell advertisement on the back and another with what looked like a Sun Solaris CD dangling from the rearview mirror as an ornament. We drove past beautiful, state-of-the-art office buildings, filled with the employees of some of theWesternworld’smost innovative companies. We dodged buffalo in the street and begrudingly yielded to rickety bicycles and full families on single mopeds. We passed by fields containing huts made from twigs, mud, tarps, and assorted garbage. We drove through crowds of well-dressed young people, drinking coffee outside their office buildings before the start of the day, only to drive a little farther to be propositioned by lepers begging at a traffic light. So before I even reached the office on my first day, my perspective had changed. This was a world of great extremes. These foreign voices I had heard through scratchy, unreliable phone connections, attached to the brains whose code I’d been ruthlessly reviewing, lived here? These are the people who are allegedly stealing our jobs? I had come to India in the first stage of the setting up of a new software development center for my company. My job was to interview and select about 25 people who would form the "seed team" of a development shop that would eventually house 250 people. More precisely, my job was to rejectmore than 200 people. We had advertised our open jobs and received nearly 30,000 applications. That’s four zeroes. You are reading it correctly. We hired outside firms to help us whittle the 30,000 down to a more manageable number and then used our own U.S.-based employees to further work that number down to a short list of a couple hundred that we could interview in person. I was to be our interview panel’s executioner, sniffing out the weak and finishing them off quickly and (I hoped) painlessly. While in India, I visited the hotel conference rooms of three different cities and met hundreds of people. I probably took a secret pleasure from the fact that I was going to go over and stop all these people from getting through the system and "stealing" our jobs. It was post-boom time. By that, I mean the DotCom bubble had burst. The IT sector’s lifestyle had gone from rock ’n’ roll to Holiday Inn lounge act, and it was showing in India as well. In fact, what I found was not an army of people, plotting to steal our comforts for themselves. Unlike their counterparts in the West, these people weren’t angry that they had to get a small television set or even that they might not be able to afford this month’s cable TV bill. These were sons and daughters who were scraping by, trying to raise money to support their parents and their spouses’ parents. These were mothers and fathers whose IT jobs meant the difference between really educating their children or sending them to a school from which the further educational options have a hard limit. They weren’t trying to steal the American dream. They were trying to squeeze a once-dry economy for a few drops of life-giving cash flow. Ultimately, I was an executioner very much fit for the task. No physical injuries resulted, but many interviewees left with bruised egos. What I left with was a changed perspective. Things had changed. A vibrant society of highly motivated and intelligent people existed here. And they weren’t playing for amenities; they were competing for the survival of their families. You can’t underestimate—or blame—someone with that kind of motivation.
Things Ain’t What They Used to Be
According to the U.S. government, IT unemployment has doubled since 2000. The Bureau of Labor Statistics reports that between 2000 and 2004, the number of programmers in the American IT industry dropped by 17%. In just the first three months of 2005, U.S. techology companies cut 60,000 jobs—twice the number cut in the same period of the previous year. The numbers are sobering. In this world in which every device seems to contain a computer, could software development be a doomed profession? Matters are made more confusing by the bipolar temperament of the IT job market. Had you left and went on retreat in a cave in 2000 for several months, you would have emerged into an IT employment landscape that was as unrecognizable as Java to a COBOL programmer. In the mid- to late-nineties, a gold rush took place in the IT industry. I remember reading about employers giving BMWs as signing bonuses. A team from another company actually auctioned itself off on eBay for a huge signing bonus. IT employment was a seller’s market, and people were jumping ship from other vocations in droves. The market was suddenly being flooded with new talent (or, at least, people who considered themselves talented). At the time, demand was still outpacing supply. I saw Java programmers being shipped in from India who seemed to have passed the time during their flights reading their first Java manual. The flood surely gave passage to some great software people. But it also introduced a large population of peoplewhowouldn’t have ever considered a career in software—and probably shouldn’t have. We’re all painfully aware that the boom has ended. When the bubble burst, it was as if an unruly bunch of children had been interrupted jumping on the bed and suddenly realized how much of a mess they had made of their room. It was a mess they now had to clean up. Our industry was filled with piles of unneeded software, hollow business models, and increasingly irrelevant people. The turn of the century sawIT being demoted fromknight to squire. Organizationally, CIOs had bubbled to the top, often reporting to their companies’ CEOs. They were now being reorg’d back down under the COOs and CFOs where they started. And with this demotion came the budget cuts. Where IT departments were previously under pressure to scoop up the best talent before the competition did, they were now under pressure to shed the excess baggage they had collected. In many cases, the reduction in force didn’t come with a reduction in workload. Bubble or not, the technology boom made our businesses more reliant on IT than ever before. Business processes from the sales floor to the call center were now resting on the backs of IT’s systems. So, here we were with way too much work to do and way too few jobs to support all the work. What’s a poor CIO to do? "Offshoring." This silly-sounding made-upword now strikes fear into the hearts of IT professionals throughout the Western world. Too much work mixed with budget reductions leaves little choice for the nation’s CIOs. Programmers in India can be hired for as low as a tenth of the salary of a programmer in the United States. And without a standardized, objective way to compare and contrast the talent difference, that’s a bargain difficult for a smart business person to turn down. Even with the time zone and cultural differences, it’s hard for a finance manager to imagine not saving real money with the right offshoring setup. So, jobs have been shipped overseas by the boatload. Many American programmers have found themselves either unemployed or supporting the skeleton crew as one of the last of a dying breed. Early-morning or late-night teleconferences through fuzzy telephone connections with people who "talk funny" are becoming a common occurrence in the software development world. And it looks like the burst of the bubble didn’t make a temporary trough. This is the new IT landscape. Over the years since the boom, offshoring has been growing at a steady rate.
In 2004, IT outsourcing grew by 37%. And according to Gartner, a research and advisory firm, worldwide offshore spending on application development will more than double, reaching $50 billion dollars by 2010. It’s not just grunt work that’s going, either. While we’re already spending $1.2 billion on R&D outsourcing, that number is expected to shoot up to $12 billion by 2010.3 The IT offshoring boom has been historically associated with India. India started with a marked advantage over many other low-cost countries, largely because of its excellent educational institutions and, more important, the prominence of English as a first or second language. But even for India, competition is heating up. More and more business is being shipped to Eastern Europe (where it’s easier to find multilingual employees to support European language–speaking nations), Russia, Malaysia, and the Phillipines, to name just a few. Most recently, China has begun to figure into the equation. You know, China. They’re the ones who manufactured almost everything in your house. Go to Wal-Mart, and try to buy a clock or a phone that wasn’t made in China. It’s a real challenge. And now, they’ve got some forward thinking Indians wondering how long the "offshoring bubble" has left in India. Leading management consultancy McKinsey & Company reports that although it will be some time before China could eclipse India in IT offshoring, progress is being made. Chinese offshoring revenues are increasing by 42% each year on average, and the number of English speaking college graduates in the Chinese workforce has more than doubled since 2000. The bottom line is that things have changed for us professional software developers here in theWestern world. All signs indicate that the change is not temporary. We can expect our DotCom bubble glory days to become a more and more distant memory as the world continues to turn to lower cost sources of software development labor.
It’s All Our Fault
It’s easy to demonize Big Money America or criticize the government for not protecting us. Or, for the truly adventurous of imagination, it’s easy to believe that Indians have developed some sinister plot to maliciously rob us of our comforts. However, even if there is an ounce of truth in these sentiments, it is outweighed by the pounds ofmediocrity underwhich our Western industry has languished for the last several years. It’s understandable that forlorn programmers would dump their personal tragedies at the feet of anonymous companies and governing bodies. It’s somehow comforting to drown one’s fear or despair in a healthy helping of anger and strategically directed blame. And to make matters worse, media sensationalists such as Lou Dobbs prey on our fears, hyping up the problem and sounding a rallying cry whose primary purpose is to get better ratings. But ultimately, blaming corporations is a dead-end road. We can’t change corporate America. And though we have democracy on our side, none of us can single-handedly steer this massive ship of a country. So though comforting in times of fear and uncertainty, this game of blame the big-guy is fruitless. We have no one to blame but ourselves. This self-blaming attitude isn’t defeatist, though. In fact, blaming the government is the defeatist choice here. Forming labor unions and picketing would be defeatist. Sitting on the couch flipping news channels and cursing in a fit of nationalist ragewould be defeatist. All these courses of action lay the blame—and the imperative for action—at someone else’s feet. If we can calm down enough to look at the situation rationally, we see that it is our own fault that we’re in this mess. We live and work in an economic ecosystem. In ecosystems, it’s the strong who survive. During a period of staggering success, we’ve allowed ourselves to get fat, lazy, and slow. The state of our craft has been marred by years of mediocrity. The fact that we can take responsibility for and see the path that led to our predicament is a good thing. It means we can start to take (and own) corrective action. It’s Up to Us It’s time to face the music. We are where we are, and waiting for things to change by themselves isn’t going to lead us anywhere different. The trends aren’t reversing, and the government has no incentive to bail us out. The good news is that each of us has the power to do something about it individually. We can each take control of our own piece of the situation, bringing sanity to the collective whole. Of course, if you can’t stand the heat, the most obvious action is to get out of the proverbial kitchen. Western IT has its share of post-boom deadweight still lingering around, nervously drawing a paycheck. For some not-insignificant percentage of IT workers, the safest bet is to start looking for an alternate line of work. Choosing when you leave and where you go next is a lot less difficult than being thrown out. If you don’t have passion and a drive that would force you to create softwarewhether you were being paid for it or not, you’re not going to be able to continue to compete with those who do. For those who remain, here is the key to survival: Software is a business. We’re going to have to be business people. Our companies don’t employ us because they love us. They never have, and they never will. That’s not the job of a business. Businesses don’t exist so we can have a place to go every day. The purpose of a business is to make money. To stay employed, you’re going to have to understand how you fit into the business’s plan to make money. As we’ll explore later, keeping you employed costs your company a significant amount of money. Your company is investing in you. Your challenge is to become an obviously good investment. If the business value you bring is clear, you are far less likely to end up on the offshoring chopping block. Think of your career as if it is the life cycle of a product that you are creating. That product is made up of you and your skills. In this book, we’ll look at four facets that a business must focus on when designing, manufacturing, and selling a product. And we’ll see how these four facets can be applied to our careers:
1. Choose your market. Pick the technologies and business domains you focus on consciously and deliberately. How do you balance risk and reward? How do supply and demand factor into the decision?
2. Invest in your product. Your knowledge and skills are the cornerstone of your product. Properly investing in them is a critical part of making yourself marketable. Simply knowing how to program in Visual Basic isn’t good enough anymore. What other skills might you need in the new economy? How can you compete with both your offshore and onshore rivals?
3. Execute. Simply having employees with a strong set of skills doesn’t pay off for a company. The employees have to deliver. How do you keep up the delivery pace without driving yourself into the dirt? How do you know you’re delivering the right value for the company?
4. Market! The best product in history won’t get purchased if nobody knows it exists. How do you get find recognition in both your company and the industry as a whole without "sucking up"?
...
Ultimately, the goal is not to bring our jobs back. These low-value jobs we’ve lost were meant to be sent offshore. Instead, we should be preparing for the new wave of higher value jobs that will be created in their places.
I awoke to an odd smell. Where am I? I asked (aloud, I think). I was in Bangalore, India’s Garden City. That odd smell was the remarkably foreign combination of pollution, ultraspicy food from the hotel’s kitchen, and something else that I could never quite put my finger on. It was my first morning there, and I was late for work. I didn’t feel bad about that, considering the hellish 32-hour journey I had suffered to get there. And that my India-savvy co-worker tricked me into an all-night cultural immersion in the world’s scariest hotel, after getting off the plane in Bombay the night before. After coming to, I felt a panic, realizing that my driver must have been waiting downstairs for an hour. Oh God, he’ll be angry, I thought, as I scrambled to get ready for the first in a series of all-day interviewing sessions. That’s just what I need on my first morning in a place like this...an angry taxi driver. I rushed downstairs, resisting the fabulous aroma of a South Indian breakfast, and ran out to ask the doorman to page my driver. I asked if the driver had been there long. He had. Two hours. Ugh. I spent the first five minutes in the car with Joseph apologizing profusely over being late and making him wait. He laughed dismissively. This is my job. I wait all day. And as I found out later, he really did. He didn’t just drop me off at work and come back at a fixed time. He waited at the office until the very minute I was ready to go. Without warning, at any time, I could come down from the office and expect to hop into the car and be driven away.
My first exposure to India in daylight was that drive across town from the northwestern corner of Bangalore to the southwestern corner. The culture shock started to hit me. Bangalore is known as India’s Silicon Valley. Being from a small city back home, it was exciting to realize that I had come to a technical mecca. More surprising, though, were the extreme contrasts between high tech and low tech. I saw half-naked children playing in the dirt in front of a huge Yahoo! sign. I saw a rickshaw with a Novell advertisement on the back and another with what looked like a Sun Solaris CD dangling from the rearview mirror as an ornament. We drove past beautiful, state-of-the-art office buildings, filled with the employees of some of theWesternworld’smost innovative companies. We dodged buffalo in the street and begrudingly yielded to rickety bicycles and full families on single mopeds. We passed by fields containing huts made from twigs, mud, tarps, and assorted garbage. We drove through crowds of well-dressed young people, drinking coffee outside their office buildings before the start of the day, only to drive a little farther to be propositioned by lepers begging at a traffic light. So before I even reached the office on my first day, my perspective had changed. This was a world of great extremes. These foreign voices I had heard through scratchy, unreliable phone connections, attached to the brains whose code I’d been ruthlessly reviewing, lived here? These are the people who are allegedly stealing our jobs? I had come to India in the first stage of the setting up of a new software development center for my company. My job was to interview and select about 25 people who would form the "seed team" of a development shop that would eventually house 250 people. More precisely, my job was to rejectmore than 200 people. We had advertised our open jobs and received nearly 30,000 applications. That’s four zeroes. You are reading it correctly. We hired outside firms to help us whittle the 30,000 down to a more manageable number and then used our own U.S.-based employees to further work that number down to a short list of a couple hundred that we could interview in person. I was to be our interview panel’s executioner, sniffing out the weak and finishing them off quickly and (I hoped) painlessly. While in India, I visited the hotel conference rooms of three different cities and met hundreds of people. I probably took a secret pleasure from the fact that I was going to go over and stop all these people from getting through the system and "stealing" our jobs. It was post-boom time. By that, I mean the DotCom bubble had burst. The IT sector’s lifestyle had gone from rock ’n’ roll to Holiday Inn lounge act, and it was showing in India as well. In fact, what I found was not an army of people, plotting to steal our comforts for themselves. Unlike their counterparts in the West, these people weren’t angry that they had to get a small television set or even that they might not be able to afford this month’s cable TV bill. These were sons and daughters who were scraping by, trying to raise money to support their parents and their spouses’ parents. These were mothers and fathers whose IT jobs meant the difference between really educating their children or sending them to a school from which the further educational options have a hard limit. They weren’t trying to steal the American dream. They were trying to squeeze a once-dry economy for a few drops of life-giving cash flow. Ultimately, I was an executioner very much fit for the task. No physical injuries resulted, but many interviewees left with bruised egos. What I left with was a changed perspective. Things had changed. A vibrant society of highly motivated and intelligent people existed here. And they weren’t playing for amenities; they were competing for the survival of their families. You can’t underestimate—or blame—someone with that kind of motivation.
Things Ain’t What They Used to Be
According to the U.S. government, IT unemployment has doubled since 2000. The Bureau of Labor Statistics reports that between 2000 and 2004, the number of programmers in the American IT industry dropped by 17%. In just the first three months of 2005, U.S. techology companies cut 60,000 jobs—twice the number cut in the same period of the previous year. The numbers are sobering. In this world in which every device seems to contain a computer, could software development be a doomed profession? Matters are made more confusing by the bipolar temperament of the IT job market. Had you left and went on retreat in a cave in 2000 for several months, you would have emerged into an IT employment landscape that was as unrecognizable as Java to a COBOL programmer. In the mid- to late-nineties, a gold rush took place in the IT industry. I remember reading about employers giving BMWs as signing bonuses. A team from another company actually auctioned itself off on eBay for a huge signing bonus. IT employment was a seller’s market, and people were jumping ship from other vocations in droves. The market was suddenly being flooded with new talent (or, at least, people who considered themselves talented). At the time, demand was still outpacing supply. I saw Java programmers being shipped in from India who seemed to have passed the time during their flights reading their first Java manual. The flood surely gave passage to some great software people. But it also introduced a large population of peoplewhowouldn’t have ever considered a career in software—and probably shouldn’t have. We’re all painfully aware that the boom has ended. When the bubble burst, it was as if an unruly bunch of children had been interrupted jumping on the bed and suddenly realized how much of a mess they had made of their room. It was a mess they now had to clean up. Our industry was filled with piles of unneeded software, hollow business models, and increasingly irrelevant people. The turn of the century sawIT being demoted fromknight to squire. Organizationally, CIOs had bubbled to the top, often reporting to their companies’ CEOs. They were now being reorg’d back down under the COOs and CFOs where they started. And with this demotion came the budget cuts. Where IT departments were previously under pressure to scoop up the best talent before the competition did, they were now under pressure to shed the excess baggage they had collected. In many cases, the reduction in force didn’t come with a reduction in workload. Bubble or not, the technology boom made our businesses more reliant on IT than ever before. Business processes from the sales floor to the call center were now resting on the backs of IT’s systems. So, here we were with way too much work to do and way too few jobs to support all the work. What’s a poor CIO to do? "Offshoring." This silly-sounding made-upword now strikes fear into the hearts of IT professionals throughout the Western world. Too much work mixed with budget reductions leaves little choice for the nation’s CIOs. Programmers in India can be hired for as low as a tenth of the salary of a programmer in the United States. And without a standardized, objective way to compare and contrast the talent difference, that’s a bargain difficult for a smart business person to turn down. Even with the time zone and cultural differences, it’s hard for a finance manager to imagine not saving real money with the right offshoring setup. So, jobs have been shipped overseas by the boatload. Many American programmers have found themselves either unemployed or supporting the skeleton crew as one of the last of a dying breed. Early-morning or late-night teleconferences through fuzzy telephone connections with people who "talk funny" are becoming a common occurrence in the software development world. And it looks like the burst of the bubble didn’t make a temporary trough. This is the new IT landscape. Over the years since the boom, offshoring has been growing at a steady rate.
In 2004, IT outsourcing grew by 37%. And according to Gartner, a research and advisory firm, worldwide offshore spending on application development will more than double, reaching $50 billion dollars by 2010. It’s not just grunt work that’s going, either. While we’re already spending $1.2 billion on R&D outsourcing, that number is expected to shoot up to $12 billion by 2010.3 The IT offshoring boom has been historically associated with India. India started with a marked advantage over many other low-cost countries, largely because of its excellent educational institutions and, more important, the prominence of English as a first or second language. But even for India, competition is heating up. More and more business is being shipped to Eastern Europe (where it’s easier to find multilingual employees to support European language–speaking nations), Russia, Malaysia, and the Phillipines, to name just a few. Most recently, China has begun to figure into the equation. You know, China. They’re the ones who manufactured almost everything in your house. Go to Wal-Mart, and try to buy a clock or a phone that wasn’t made in China. It’s a real challenge. And now, they’ve got some forward thinking Indians wondering how long the "offshoring bubble" has left in India. Leading management consultancy McKinsey & Company reports that although it will be some time before China could eclipse India in IT offshoring, progress is being made. Chinese offshoring revenues are increasing by 42% each year on average, and the number of English speaking college graduates in the Chinese workforce has more than doubled since 2000. The bottom line is that things have changed for us professional software developers here in theWestern world. All signs indicate that the change is not temporary. We can expect our DotCom bubble glory days to become a more and more distant memory as the world continues to turn to lower cost sources of software development labor.
It’s All Our Fault
It’s easy to demonize Big Money America or criticize the government for not protecting us. Or, for the truly adventurous of imagination, it’s easy to believe that Indians have developed some sinister plot to maliciously rob us of our comforts. However, even if there is an ounce of truth in these sentiments, it is outweighed by the pounds ofmediocrity underwhich our Western industry has languished for the last several years. It’s understandable that forlorn programmers would dump their personal tragedies at the feet of anonymous companies and governing bodies. It’s somehow comforting to drown one’s fear or despair in a healthy helping of anger and strategically directed blame. And to make matters worse, media sensationalists such as Lou Dobbs prey on our fears, hyping up the problem and sounding a rallying cry whose primary purpose is to get better ratings. But ultimately, blaming corporations is a dead-end road. We can’t change corporate America. And though we have democracy on our side, none of us can single-handedly steer this massive ship of a country. So though comforting in times of fear and uncertainty, this game of blame the big-guy is fruitless. We have no one to blame but ourselves. This self-blaming attitude isn’t defeatist, though. In fact, blaming the government is the defeatist choice here. Forming labor unions and picketing would be defeatist. Sitting on the couch flipping news channels and cursing in a fit of nationalist ragewould be defeatist. All these courses of action lay the blame—and the imperative for action—at someone else’s feet. If we can calm down enough to look at the situation rationally, we see that it is our own fault that we’re in this mess. We live and work in an economic ecosystem. In ecosystems, it’s the strong who survive. During a period of staggering success, we’ve allowed ourselves to get fat, lazy, and slow. The state of our craft has been marred by years of mediocrity. The fact that we can take responsibility for and see the path that led to our predicament is a good thing. It means we can start to take (and own) corrective action. It’s Up to Us It’s time to face the music. We are where we are, and waiting for things to change by themselves isn’t going to lead us anywhere different. The trends aren’t reversing, and the government has no incentive to bail us out. The good news is that each of us has the power to do something about it individually. We can each take control of our own piece of the situation, bringing sanity to the collective whole. Of course, if you can’t stand the heat, the most obvious action is to get out of the proverbial kitchen. Western IT has its share of post-boom deadweight still lingering around, nervously drawing a paycheck. For some not-insignificant percentage of IT workers, the safest bet is to start looking for an alternate line of work. Choosing when you leave and where you go next is a lot less difficult than being thrown out. If you don’t have passion and a drive that would force you to create softwarewhether you were being paid for it or not, you’re not going to be able to continue to compete with those who do. For those who remain, here is the key to survival: Software is a business. We’re going to have to be business people. Our companies don’t employ us because they love us. They never have, and they never will. That’s not the job of a business. Businesses don’t exist so we can have a place to go every day. The purpose of a business is to make money. To stay employed, you’re going to have to understand how you fit into the business’s plan to make money. As we’ll explore later, keeping you employed costs your company a significant amount of money. Your company is investing in you. Your challenge is to become an obviously good investment. If the business value you bring is clear, you are far less likely to end up on the offshoring chopping block. Think of your career as if it is the life cycle of a product that you are creating. That product is made up of you and your skills. In this book, we’ll look at four facets that a business must focus on when designing, manufacturing, and selling a product. And we’ll see how these four facets can be applied to our careers:
1. Choose your market. Pick the technologies and business domains you focus on consciously and deliberately. How do you balance risk and reward? How do supply and demand factor into the decision?
2. Invest in your product. Your knowledge and skills are the cornerstone of your product. Properly investing in them is a critical part of making yourself marketable. Simply knowing how to program in Visual Basic isn’t good enough anymore. What other skills might you need in the new economy? How can you compete with both your offshore and onshore rivals?
3. Execute. Simply having employees with a strong set of skills doesn’t pay off for a company. The employees have to deliver. How do you keep up the delivery pace without driving yourself into the dirt? How do you know you’re delivering the right value for the company?
4. Market! The best product in history won’t get purchased if nobody knows it exists. How do you get find recognition in both your company and the industry as a whole without "sucking up"?
...
Ultimately, the goal is not to bring our jobs back. These low-value jobs we’ve lost were meant to be sent offshore. Instead, we should be preparing for the new wave of higher value jobs that will be created in their places.
web 2.0 & web 3.0
I spent a little time this weekend looking at aspects of web 2.0 and 3.0 and how these can be relevant to the business world. Of course in NG we are using such ideas as wiki. Its amazing how helpful the wikipedia site has become to me. Anyway, sites such as myspace are interesting if nothing else than just to note that this site is now the 6th most popularly accessed site in the entire WORLD. We really do all need to be at least cognizant of the ways the younger generation (such as my son) is using the web in the context of social engineering. How might we use these ideas ourselves? Perhaps not to find a date….but perhaps to make an important IT or business connection? (or even to find a date for myself…LOL) Okay…so young folks are using the web in drastically revolutionary ways and it seems that us *older* folks are always behind. Anyway, I have picked up some books on things such as ajax and am looking forward to getting caught up a little with some of the newer technologies. Of course ajax is already mainstream. I read a book this week that provides some *excellent* ideas on thought leadership. You might not know it looking at the book cover and title, which is "My Job Went to India and all I got was this Lousy Book". The book cover shows a rather forlorn looking guy on the street holding a sign saying "Will Code for Food". I picked up the book because I found the cover amusing. But inside I found gems of wisdom. Probably the most important book I have read in ten years. Now I just need to go about putting into action some of the author's suggestions. :-) Anyway, its interesting to type in some words on the Google Trends page. You can type in a word such as J2EE and see that top most requested searches for that word are almost all coming from India. But if you look at the Google Trends for something such as Ruby for Rails you see that those searches mostly come from Silicon Valley and the area around MIT. This is just one small way to kind of monitor what the top IT gurus are up to. The idea is that J2EE is already well commoditized and is being off-shored. If someone starts today to learn J2EE they are already *far* behind the curve. I think an important area to watch is the Semantic Web. I think this is one area that is going to absolutely explode. How might the SOA, BPM, and the Semantic Web converge? What might become possible with the convergence of these 3 ideas? How might we use that convergence to help our customers? Anyway, just things to think about…
By the way, if anyone is ever bored (which I know we never are…), you might go to http://99-bottles-of-beer.net and peruse through the syntax of a simple algorithm in some 1,069 languages. This is just an amusing thing to do…. A little more exciting than programming "Hello World"...
By the way, if anyone is ever bored (which I know we never are…), you might go to http://99-bottles-of-beer.net and peruse through the syntax of a simple algorithm in some 1,069 languages. This is just an amusing thing to do…. A little more exciting than programming "Hello World"...
Jess
Jess is a rule engine for the Java platform, and is a superset of CLIPS programming language, developed by Ernest Friedman-Hill of Sandia National Labs. In at least one (possibly two) of my expert systems classes I actually wrote some programs in the CLIPS language. Jess provides rule-based programming suitable for automating an expert system, and is often referred to as an expert system shell. In recent years, intelligent agent systems have also been developed, which provide a similar capability. Rather than a procedural paradigm, where a single program has a loop that is activated only one time, the declarative paradigm used by Jess continuously applied a collection of rules to a collection of facts by a process called pattern matching. Rules can modify the collection of facts, or they can execute any Java code. Jess can be used to build Java applets as well as full applications that use knowledge in the form of declarative rules to draw conclusions, and inferences.
Options for Legacy SOA-Enablement
Legacy integration aims to revitalize and extend the reach and lifetime of legacy systems by exposing existing functionality through the use of wrapping. It adds a front-end software layer to hide unwanted complexity and exposes modern interfaces to ease interoperability. The options for integrating legacy systems are:
User-interface wrapping or screen scraping, where legacy screens are mapped into modern graphical or Web service interfaces. Advances in the capabilities of Web-based, screen-scraping products make development of these interfaces easier with nominal development effort. However, this option makes sense only for applications that are user-interface intensive.
Data wrapping, where new interfaces are developed for the legacy data structures to allow direct access using standard SQL or XML technologies.
Business-logic wrapping, where legacy functionalities are wrapped and programmatically accessed through custom object-oriented wrappers, EAI adapters, or Web Services interfaces.
Legacy wrapping requires less up-front architecture and design, and it can reduce integration costs and provide a roadmap to incrementally reengineer and transfer legacy components to a new platform without having to go through a "big bang" type of replacement of the system. However, legacy wrapping can only provide a tactical, short-term solution because it addresses the integration and flexibility pain points without impacting the source code significantly. True flexibility will be achieved only by understanding the legacy source code repository and refactoring it to some extent.
User-interface wrapping or screen scraping, where legacy screens are mapped into modern graphical or Web service interfaces. Advances in the capabilities of Web-based, screen-scraping products make development of these interfaces easier with nominal development effort. However, this option makes sense only for applications that are user-interface intensive.
Data wrapping, where new interfaces are developed for the legacy data structures to allow direct access using standard SQL or XML technologies.
Business-logic wrapping, where legacy functionalities are wrapped and programmatically accessed through custom object-oriented wrappers, EAI adapters, or Web Services interfaces.
Legacy wrapping requires less up-front architecture and design, and it can reduce integration costs and provide a roadmap to incrementally reengineer and transfer legacy components to a new platform without having to go through a "big bang" type of replacement of the system. However, legacy wrapping can only provide a tactical, short-term solution because it addresses the integration and flexibility pain points without impacting the source code significantly. True flexibility will be achieved only by understanding the legacy source code repository and refactoring it to some extent.
service wrapping of legacy systems
Research efforts and commercial providers have proposed various approaches to address the pain points of legacy systems. However, the major problem remains: the identification of useful legacy functionality that can be exposed for collaborating applications at an optimal level of granularity. Additionally it is important to estimate and analyze the consequences of service-enablement decisions on the system-quality attributes (such as performance and maintainability) and the solution cost. In this regard, a systematic and comprehensive method to guide the transformation and integration of legacy applications with an enterprise-level architecture such as service-oriented architecture (SOA) is currently lacking. SOA using Web Services is gaining acceptance as the primary mechanism to interconnect disparate applications and ease interoperability between heterogeneous systems for internal as well as external integration. It promises improved business agility and reduced integration costs through increased interoperability and reuse of shared business services. One of the key obstacles to realizing this vision is the service enablement of existing legacy applications to collaborate in an enterprise-wide SOA. Over the past few years, significant advancements have been made to modernize and improve the interoperability of legacy systems.
What is the semantic web?
Wikipedia states: “Humans are capable of using the Web to carry out tasks such as finding the Swedish word for "car", to reserve a library book, or to search for the cheapest DVD and buy it. However, a computer cannot accomplish the same tasks without human direction because web pages are designed to be read by people, not machines. The semantic web is a vision of web pages that are understandable by computers, so that they can search websites and perform actions in a standardized way. A computer could, for example, automatically find the nearest manicurist or book an appointment that fits a person's schedule.”
I predict a really cool convergence between SOA, BPM, and the semantic web sometime in the future.
I predict a really cool convergence between SOA, BPM, and the semantic web sometime in the future.
Subscribe to:
Posts (Atom)
