Virtual Pragmatics

You don't have to be a technologist to be a geek...

Tax time reminds me that there are all manner of fields that have masses of obscure detail, and jargon to go with them.  In doing a bit of homework for filing this year's return, I ran across this gem of a sentence:

Have you ever wondered what happens to the Section 1250 excess depreciation recapture when depreciable real estate is exchanged [for] other depreciable real estate under IRC 1031 or IRC 1033?

Uh, no.  It took reading the sentence to even imagine that there was such a thing to wonder about, and maybe I'm just tired but it cracked me up.  It's funny to me, because I've read and written and talked about dozens or hundreds of similarly obscure concepts as though everybody wonders about them... which ain't necessarily so. 

Here's to the geeks, no matter where they are.

Reliability vs. Efficiency

If your life is going too smoothly right now, and you need to inject a little insomnia into your evenings, you could do worse than follow the posts and discussion at The Oil Drum: Discussions about Energy and Our Future.  'Peak Oil' is just one of many dismal trends covered, along with speculation about the problems and solutions surrounding the world's energy supply.  The posts and their comment threads are an education.

There was a fascinating post recently, "The Failure of Networked Systems", which generalized from the following observation:

The problem was eventually traced to a problem with one piece of software on one machine on our intranet. The software drivers for the network interface card on one machine were corrupt.

This raised a question in my mind: The Internet Protocol was originally designed to be a robust, reliable, redundant system. How does one piece of software on one machine bring down a network with thousands of nodes?

The answer is easy: Cost efficiencies.

Our Intranet network could have been built to be reliable, but instead it was built to be "efficient". Far from being a network of fail-safe systems, our network is a network of interdependencies. When the system was loaded, a single failure brought the whole system down. "Business Efficiency" has brought our network to its knees for two consecutive days.

If you're not bored already, the entire post is worth your time, as he gos on to draw what I think are useful analogies between an ip network crash and the potential for crashes in our energy, economic and financial networks, as these are increasingly engineered for efficiency over reliability, and as their usage is approaching their capacity. 

In perhaps overly simple terms, the basic way to achieve reliability is to keep spares, like a spare set of keys for the house or car, or a generator in your garage for when the power company is having trouble. Fault-tolerant computer systems rely on multiple copies of the resources they're to protect from faults.

Again in perhaps overly simple terms, the basic way to achieve efficiency is to get rid of spare capacity, like only having one car instead of two, or a smaller staff, supported by more automation, or multiple virtual servers running on a single machine. 

This pits reliability against efficiency in mortal combat, as they are very often in opposition. Business, by and large, seeks to develop efficiencies, whether in execution, like FedEx, or economies of scale, like Wal-Mart.  Government, by and large, seeks to offer reliability, whether in law enforcement, defense, social safety nets, like Social Security, or standards for thinks like water, food, non-toxic materials. 
Efficiency has been the dominant meme, perhaps since the industrial revolution.  Reliability may need to be brought back in to focus in the near future, I think.

Google 101

Nice article in Business Week on Google's notion of cloud computing, and the guy behind evangelizing it.

Excerpt:

One simple question. That's all it took for Christophe Bisciglia to bewilder confident job applicants at Google (GOOG). Bisciglia, an angular 27-year-old senior software engineer with long wavy hair, wanted to see if these undergrads were ready to think like Googlers. "Tell me," he'd say, "what would you do if you had 1,000 times more data?"

What a strange idea. If they returned to their school projects and were foolish enough to cram formulas with a thousand times more details about shopping or maps or—heaven forbid—with video files, they'd slow their college servers to a crawl.

At that point in the interview, Bisciglia would explain his question. To thrive at Google, he told them, they would have to learn to work—and to dream—on a vastly larger scale. He described Google's globe-spanning network of computers. Yes, they answered search queries instantly. But together they also blitzed through mountains of data, looking for answers or intelligence faster than any machine on earth. Most of this hardware wasn't on the Google campus. It was just out there, somewhere on earth, whirring away in big refrigerated data centers. Folks at Google called it "the cloud." And one challenge of programming at Google was to leverage that cloud—to push it to do things that would overwhelm lesser machines. New hires at Google, Bisciglia says, usually take a few months to get used to this scale. "Then one day, you see someone suggest a wild job that needs a few thousand machines, and you say: Hey, he gets it.'"

What recruits needed, Bisciglia eventually decided, was advance training. So one autumn day a year ago, when he ran into Google CEO Eric E. Schmidt between meetings, he floated an idea. He would use his 20% time, the allotment Googlers have for independent projects, to launch a course. It would introduce students at his alma mater, the University of Washington, to programming at the scale of a cloud. Call it Google 101. Schmidt liked the plan. Over the following months, Bisciglia's Google 101 would evolve and grow. It would eventually lead to an ambitious partnership with IBM (IBM), announced in October, to plug universities around the world into Google-like computing clouds.

FreeRice

FreeRice has two goals:

1. Provide English vocabulary to everyone for free.
2. Help end world hunger by providing rice to hungry people for free.

The Right Pen

Sometimes a little planning in advance can go a long way.  Sometimes the best way to recognize that is to live with the alternative. 

Yesterday, I drove up to the FAU campus to get the signatures I needed for my master's thesis.  I'd collected the signatures of my committee at the defense (successful, hooray!), but still needed sign-off from the department chair, and the college's dean.  As I was walking in to the building, the department chair is walking out, on the way to lunch.  He asked if I had the right pen (a felt-tip, nothing else will do, per the graduate studies standards).  Having only a ballpoint in hand at that moment, I had to say no.  He said he'd be happy to sign, when he returned from his lunch appointment, in an hour and a half.

I reason, well, this gives me a chance to walk over to the campus bookstore and pick up the right pen.  As it turns out, after investigation and inquiry, the bookstore doesn't carry felt tip pens.   Off to Office Depot, where I pick up a variety of pens, to be sure I'm prepared for the next go 'round.  I manage to get back to the office by the time the chair does, and gain his signature and that of the dean's without further delay.  I left the dean with one of the pens, as a sympathy offering for the next unprepared student.

But I could have saved myself about and hour and a half, and a certain amount of frustration, by reading the instructions carefully and by preparing myself accordingly, rather than depending on someone else to be prepared for me. 

NLBP: Next Logical Break, Please.

I was working the list of completed issues and testing them out on the staging server when I ran into a question that I wanted to ask of the guy sitting right across from me.  We went through a dialogue I've been through hundreds of times, as both interuptor and interuptee, where the interruptor asks something like 'Got a minute?', which might mean 20 seconds or half-an-hour, and the interuptee says something to the effect of 'not now, give me 5 minutes', or something to that effect, to allow time to complete a thought/process step/whatever.

This time we joked about the need for vocabulary for this, and we came up with the phrase "Next Logical Break, Please", and its shorthand, "NLBP" to handle the interuptee's side of things. 

Experts: not born, but made.

Just read an interesting article in Scientific American online on the topic of how expertise is developed.  Any fragment is just that, but here's one that suits my ends:

Ericsson argues that what matters is not experience per se but "effortful study," which entails continually tackling challenges that lie just beyond one's competence. That is why it is possible for enthusiasts to spend tens of thousands of hours playing chess or golf or a musical instrument without ever advancing beyond the amateur level and why a properly trained student can overtake them in a relatively short time. It is interesting to note that time spent playing chess, even in tournaments, appears to contribute less than such study to a player's progress; the main training value of such games is to point up weaknesses for future study.

As one who has spent "tens of thousands of hours" programming and not getting particularly better... AND as one who has from time to time taken leaps forward in my ability, I suspect that there are lessons to be learned for those wishing to improve computer science education and software development practice, whether at the company, team or personal level.  I further suspect that that TDD and pair programming are two pieces of the puzzle that lead to programmers doing more "effortful study" in their work.

Article: http://www.sciam.com/article.cfm?articleID=00010347-101C-14C1-8F9E83414B7F4945

Travel To/From Consulting Skills Workshop

I'm attending Jerry Weinberg's Consulting Skills Workshop, in Rio Rancho, NM at the end of the month.

I'm schedule to arrive in Albuquerque just after 1pm on Sunday the 26th, and am scheduled to leave at 3pm on the 31st.  Given that my main use of a vehicle would be to drive to and from the airport, my inclination would be to take a Super Shuttle or local equivalent to the hotel and back, and walk/catch rides as needed in between but...

If there are one or more people arriving/departing at similar times who would consider pooling resources to rent a car/van, I'd be game for that as well.  I'm not anticipating much use of the car between arrival and departure, so an ideal match would be with someone who anticipated going places while in New Mexico.

Post a comment if you're interested.  If this goes anywhere, we can work out terms, swap cell #'s, decide who's going to reserve the vehicle (I don't mind doing that), etc...

The wisdom of the elders...

From the 1968 NATO Software Engineering proceedings (available here):

Kinslow: The design process is an iterative one. [...] In my terms design consists of:

1. Flowchart until you think you understand the problem.
2. Write code until you realize that you don’t.
3. Go back and re-do the flowchart.
4. Write some more code and iterate to what you feel is the correct solution.

I used to feel bad when my first plan didn't work the way I thought it would.  It would seem that this is just part of the process of discovering knowledge. 

Paul Graham, on Procrastination....

Dr. Graham writes:

In his famous essay You and Your Research (which I recommend to anyone ambitious, no matter what they're working on), Richard Hamming suggests that you ask yourself three questions:

1. What are the most important problems in your field?
   
2. Are you working on one of them?
   
3. Why not?