Software Nerd

Friday, March 04, 2005

Look-say

"Look-say" is a good term to describe the way kids should learn many concepts. Point at a table (not the word "table") and tell the kid it is a table. Concepts of consciousness are also learned this way. In response to a child remembering something, you comment "oh, you remember that!" Implicitly, you are "pointing" to the mental process the child just underwent and telling him it is "remembering". As with the table, you isolate a particular element of reality and name it.

Unfortunately, the term is "taken". "Look-say" describes a faulty way of teaching children to read. A child may learn a particular word by looking at the word. Teaching phonetically means teaching the kid to read any word.

For more on phonetic/look-say in reading, see...Why Johnny Can't Read

Thursday, March 03, 2005

Outsourcing

Recently"ComputerWorld" quoted a consultant from "Bain Partners" saying that firms need notkeep "core functions" in-house. Instead, anything that someone else can do cheaper or better should be outsourced. Is this actually a sign that outsourcing is passe?

The constant drone about outsourcing is tiring. I stopped watching Lou Dobbs's program on CNN because he insists on a daily dose of anti-immigration and anti-outsourcing propoganda. Mercantilists are alive and well... Adam Smith, turn in your grave!

"Outsourced jobs"? What does that mean? For decades, the US has been importing more of certain items from China. Wasn't that a similar "outsourcing of jobs"?

Before the Chinese, it was the Japanese who were going to buy up America. Does anyone remember "quality circles"? I'm even old enough to remember when U.S.S.R. was supposed to overtake the U.S. (None other than Paul Samuelson made the projection...but then he's a Nobel-prize winning economist like those guys at "Long Term Capital". They don't take reality too seriously.)

Did the Japanese decimate the US? Many US factories closed and some towns went downhill. On the other hand, South Eastern Michigan -- the heart of the auto industry -- is a rich place even 20 years later.

Similarly, Chinese imports have probably had a much more detrimental effect on jobs in certain industries -- for instance, the US shoe industry. However, the overall effect of the increased trade with China has been great -- cheap goods and a higher standard of living for Chinese and for Americans.

It's funny how industry after industry has "died" (e.g. Steel) and the economy as a whole has continued to flourish! I think two facts can be learnt from this history:
  • Global trade is good "on the average"
  • Sudden changes in the pattern of global trade can cause upheavals in certain industries

Importing certain goods from China has been great for the US economy. Importing services from India will be similar. Rational outsourcing is a good thing for the U.S. Having laid that to rest, there is still a question about the software industry in particular. Will the US software industry be decimated by cheap India programmers? Will all those Indian super-programmers run people like me out of a job?

That's a topic for another post.

Pair programming

I've seen many projects where a single guru has the bulk of the knowledge and hates to give it up. Knowledge is perceived as power ... and job-security.

Some "agile folks" propose to solve this through "pair programming": let two programmers work together. Literally together -- they share a desk and look at the same computer screen at the same time.

Riddle: How does a US software shop compete against Indian firms and other low-cost providers of software developers?

Answer: Doubling the number of programmers being paid in dollars! Pair programming does not make economic sense.

Sometimes (very, very rarely) one might have a situation where it is dangerous to have the work of the last week in any single programmer's head. Most of the time, if we were to work individually Monday through Thuirsday, and spend Friday "sharing", we'd be far more competitive. [No, I'm not suggesting that as a methodology...just saying that it would work better than pair-programming.]

A truly "agile" developer would stop me here to point out that "two heads think better than one".

A serious reply to that is: "Baloney!"

I know that often two good programmers can help each other by bouncing ideas off each other a few times each week. But, the rest of the time, they're coding out their ideas, and tweaking them into shapes they did not anticipate. Having them sit at a terminal together would always slow them down and result in less ambitious code.

In practice, managers who are forced into pair-programming will team a bad (or simply inexperienced) programmer with a good programmer. Typically, the net product of the pair will be less than the good guy working alone and not having to explain himself constantly. A friend once had a partner who came, sat on the chair behind, and slept! He said that was the best partner he'd ever had!

There are ways to overcome person-dependency; pair programming is not it.