Thursday, September 18, 2008

Ramp It Up

I've been noticing lately, and it may have to do with the new location I moved to and my new commute, that it's fairly common for people, as they get on the interstate, to not fully utilize the on-ramp.

Here's the idea: you need to get on the interstate. It's a major freeway, traveling at high speeds. There's this "on-ramp" that's to be used to speed up to sufficient speed to appropriately merge with the rest of the traffic already on the freeway. The whole point of this is to prevent the need to put stop signs or traffic lights on the freeway (thus, increasing the speed and throughput of traffic). There's nothing new here, as these freeways and the on-ramps have been in existence for decades.

So, why is it that many people don't fully utilize them by "getting to merge speed" before attempting to merge with existing traffic? Too often, I've been stuck behind a car trying to merge that's going much slower than needed, which causes them (and, since I'm behind them, me, as well) difficulty in merging (in some cases, causing a very dangerous situation). It's frustrating.

It's like in development, where you're working with a team, and you're dependent upon some code, interface, module, or whatever from another developer. This developer may be fast or slow, but if their work was properly planned out, it was to be delivered to you by a certain date or time. But, because they figured they had plenty of time, they lazily worked toward completing their task. I guess they figure they'll get it done, but when they don't, their surprised. It ends up messing up your own schedule, and could potentially cause some serious delays in the overall project. Why didn't they accelerate appropriately so that they could safely merge? Why didn't they work hard, right off the bat, making sure they were well ahead of schedule (or, at least, well on schedule)?

It's just downright frustrating.

And they wonder where coding rage comes from...

Saturday, April 26, 2008

Sometimes, You Just Have to Start Over

I have no sense of direction. That basically means that I get lost easily (of course, with the new GPS device that I just bought, I should be okay). So, sometimes, when I take the wrong direction, I have to back-track to a known location and "try again." Of course, getting back to a known location can sometimes be difficult.

The same goes for reading: I love to read, but sometimes, my attention wonders. That's kind of embarrassing when you're reading (the good thing is that, usually, nobody notices). But, it happens: I'm reading along and realize that I don't understand what's going on in the current paragraph because I wasn't paying attention in the last couple, so I have to go back and figure out how I got there.

Same goes for building things. If you build a paper airplane, and you get one of the folds slightly off, most of the rest of the folds will get messed up, which means poor performance when you launch the thing. I hate that; especially when I'm trying to impress one of my kids with my great airplane-making skills (I have none, but they don't know that...at least, not yet).

The same goes for programming. After receiving a few enhancement requests for my open source project (iScreen at i-screen.org), I realized that in order to do some of them, it would take more than just a quick patch or added code. I'd have to revisit some of the basic approaches I took with the project. So, sometimes you have to just start over.

Of course, not literally. There's no point not leveraging what you have that's good (if you can). So, I won't have to rewrite the entire framework from scratch, since I'll be able to leverage most of what's there. But, I'll have to "start over" on some of the basic approach. Ouch. Guess that airplane's performance wasn't as great as I'd hoped.