What’s Under A Tree? November 26, 2008
Posted by Chuck Musciano in Random Musings.Tags: Conundrums
3 comments
Why isn’t there an enormous hole under every tree?
Plant a seed and a tree grows. Small at first, but becoming huge, until a multi-ton organism towers over your head. Everything above you was once below you, drawn in microscopic amounts from the ground through the roots and sent upward to form new branches and leaves.
Granted, a lot of the tree is water, but a lot of it is not. A tree is just hundreds and hundreds of pounds of minerals and base elements, attractively arranged in the shape of an elm or maple. If all those elements were drawn from the ground under the tree, why isn’t there a hole of equal size under the tree? Why doesn’t the tree slowly slump into the ground as it grows? Just the volume of dead leaves each year is easily larger than a toddler; is there a new toddler-sized cavity under each tree each year?
I’ll concede that equivalent material may be drawn from around the tree to replace what was pulled up to create it, so that may be the answer in the wild. But what about potted plants? I have a plant in my office that has more than doubled in size in the past year. Originally eighteen inches tall, it’s now easily over three feet, but it still lives in a little pot no more than eight inches square and three inches deep. I’m guessing that if I took all the new growth on the plant and crushed and compressed it into a block, the block would not fit in the pot. How can this be?
I await any rational explanation.
Know Who Knows November 24, 2008
Posted by Chuck Musciano in Leadership, Networking.Tags: Best Of 2008, Leadership, Networking
1 comment so far
Early in my career, I worked with two mathematicians who had been in computing since the very beginning. They had all these great stories about using Fortran for the first time, and drum memory, and mercury delay lines. They were brilliant and eccentric and were both named George. George Haynam was called “George” and George Petznick was called “GP” just to avoid confusion.
The neat thing about either George was that they did not immediately know the answer to most mathematical questions. Instead, they knew how to derive the answer from first principles. Once, I asked GP for the formula for standard deviation. He stood up at his blackboard (a real blackboard with chalk and dust) and, recalling that the standard deviation is just the square root of the variance integrated about the center of mass of the sample space, quickly derived the discrete formula. Simple! The running joke in the department was that the Georges could figure out anything, starting with f=ma.
This all came back to me recently as I was discussing aspects of successful leaders. I pointed out that, in most cases, I don’t need to know the answer to something. I just need to know who knows, so I can get the answer from them. If my network is robust and current, and I surround myself with people smarter than me (very easy to do), the “know who knows” model always works.
This is true for everyone, of course, but I don’t think we coach our teams to value and use this trick. Instead, we have lots of people on our teams who try to be cowboys, singlehandedly trying to know everything and solve everything. As they move up the management chain and realize they can’t know everything, they begin to adopt the “know who knows” approach. Unfortunately, it takes a while to learn this lesson. Some people never do.
People at every level can dramatically increase their value by developing their network of “people who know things” along with their collection of “things they know themselves.” The sum of both parts is substantially larger than everything they can hope to know, but that lesson isn’t learned right away.
As effective leaders, we need to explicitly teach this lesson to our people and offer opportunities for them to build their networks of “people who know.” Social tools help, of course, but so do real social interactions with experts: training, conferences, seminars, etc. Force your people to engage others as they solve problems, and show them how to fall back on their networks early in the problem-solving process, not as a last resort. That lesson, learned early, can make a huge difference in the course of a career.
Another Web Irritant November 21, 2008
Posted by Chuck Musciano in Technology.Tags: Interfaces, Irritants, Software
2 comments
I understand that advertising helps keep vast swaths of the web free. I respect a site’s right to sell ads; I just wish they would respect my intelligence.
The latest affront to my self-esteem comes along with interstitial ads, those full-page popups that appear for a fixed period of time before letting you see the real content you were seeking. I don’t mind the ads; that’s part of life, and that’s why Firefox has all those clever ad-blocking plug-ins.
I do mind the inane message that accompanies the ad, the one that says something to the effect of “Please wait while your page is loading…” While my page is loading? Come on!
I suppose there are some folks who may think that web pages are handcrafted as you request them, with teams of web artisans standing by to put all that content together in the fifteen seconds that the ad stays on your screen. For those folks, it may seem like a courtesy to provide something to look at, instead of a blank screen and an hour-glass cursor.
If only they knew the exact opposite: your page starts rendering after the ad goes away, and the twenty-something web designer who put that “Please wait” message on your screen got a snarky chuckle over getting away with such a blatant, insulting lie. It’s as if a full page ad in a print magazine had a tag line at the bottom: “Please wait for fifteen seconds while we print the next page.”
How about a little truth in advertising? I’d much prefer a message like “Please, please take a moment to look at this ad. We’re running out of VC funding, and unless we get some positive cash-flow out of our ad-based revenue model, I’ll be looking for my fifth job in three years.” If I see that message on my screen, I’ll not only read the ad, I’ll click through just for good measure!
Old School Email November 19, 2008
Posted by Chuck Musciano in Technology.Tags: Email, History, Software
2 comments
Technology matures, and expectations change. Email, designed to be a slow, reliable messaging system, is now expected to be instantaneous. I’ve seen people send an email and then pick up the phone to call to see if it had arrived!
Twenty-five years ago, email was a hodge-podge of technologies, linking wildly different systems using all sorts of connections. Getting a message from here to there often required knowledge of your system, the recipient’s system, and all those in between. Email might take days to arrive, and never made it in just a few seconds. A well-connected site could get a message in a few hours, which was considered really good performance.
Our modern person@place.com addressing scheme masks a huge amount of complexity. Your message may actually travel among many nodes on the network to get to its final destination, and individual pieces of your message may take different routes before being reassembled at the end. You don’t worry about all of this, of course; you just click “Send” and magic happens.
This simplicity didn’t exist back then. Instead, your email address changed depending on where the message originated. In essence, your address was the route your message would take to get to where it was going. Each stop along the way was named, separated by exclamation points (known as “bangs”). Thus, the “bang path” for my email back in 1984 looked something like this:
...!gatech!mit!trantor!chuck
When the message arrived at the Georgia Tech server, it would be sent to the MIT server, which sent it to my server (trantor), which delivered it to me. The “…” was important; you replaced it with whatever you needed to get from your machine to the Georgia Tech server.
You were expected to know what to put in place of that “…” and if you didn’t, tools existed to help you figure it out. A vast database (ahem, “flat file”) listing every node in the network was sent around every so often. For each node, you could see what other nodes they would connect to, and from that list you could construct a route for your message. If your path to Georgia Tech was through kremvax and wustl, your address for me would be
kremvax!wustl!gatech!mit!trantor!chuck
You may wonder why every node didn’t just connect to every other node. Another historical fact comes into play: phone calls used to cost money, charged by the minute and varying by the length and distance of the call. Given tight budgets, each site would only call to other, nearby sites. Cross-country calls were rare, especially for lengthy data transmissions. Sending email overseas was almost unheard of. Instead, you built a route of short hops, constrained by local phone charges, and hoped for the best
To further reduce costs, sites only dialed out every so often, and sometimes only at night. After your message arrived at a site, it might sit for a day before the next scheduled transmission. If that transmission failed, it would sit for another day before a retry occurred. Mail moved, but it moved slowly.
As the modern internet began to grow, addresses began to merge. You might use part of a bang path after sending to an internet host:
trantor!chuck@mit.edu
Networks were not completely interconnected, so you might route through a gateway between two networks:
chuck%trantor.harris-atd.com@gatech.edu
It was confusing, constantly changing, and not for the faint of heart.
In comparison, email today is easy. Back in the day, email had to go uphill, through the snow, both ways, all the time. But when mail got through, you felt like you had accomplished something! So be thankful, and be patient. Try to wait at least ten minutes before calling to check on your latest urgent message.
Lazy Developers November 17, 2008
Posted by Chuck Musciano in Technology.Tags: Interfaces, Irritants, Software, Users
add a comment
You see it all the time on web forms: the little bit of “advice” next to entry fields for phone numbers and credit cards: “No dashes or spaces.” This drives me crazy!
Let’s understand this: the developer is asking you, the unfortunate user, to make sure you enter data correctly to match what he needs. Because… it’s so hard for computers to get rid of characters that aren’t numbers? No. Because the developer is too lazy to write the code to get rid of the unwanted characters you may type.
Ever type in a phone number with dashes, only to be dinged with an error popup chastising you to not type the dashes? Ever put spaces in a credit card number only to be similarly admonished? If so, you have been the victim of a lazy developer, one who deserves to have their keyboard seized and their pocket protector revoked. That’s shameful coding, and it should be punished.
In case you were wondering, it is trivially simple to automatically remove non-numeric stuff from numeric fields. Actually, it’s trivially simple to configure the field to keep you from typing them in the first place. It actually takes a lot more work to check for the errant characters and pop up a window to irritate you that it does to fix the $%&^# field in the first place! Bad developers will spend more time writing bad code that irritates the user than they will writing good code that makes life easier for the user. Go figure.
All software development is about the end user experience. Period. The user experience should be natural, easy, forgiving, and rewarding. It should not be filled with pedantic errors and foolish activities better left to the machine. Developers who develop anything less should be ashamed, and user should complain vociferously when they are forced to use such systems. Stand up and demand better!
The Effective CIO 