Wednesday, January 16, 2008

Priorities

1. Make it necessary.

Don't do a project if it's not important and necessary. The basis of
all efficiency is not using resources when you can avoid using the
resources. If you can avoid doing the work, then don't do it.

2. Make it work.

First, get the thing working. Prove that it's possible. Demonstrate
that it's necessary. Build it as simple and as lightweight as
possible; as the Extreme Programming folks say, build the "Simplest
thing that could possibly work". Avoid using newfangled features if
they don't help.

3. Make it beautiful.

Refactor and re-organize to make it aesthetically attractive, and
understandable. Make it "fit in your head". Implement it using the
right layers; "do things at the highest layer possible", as Linus
Torvalds said at USENIX 1997 of the Linux kernel design philosophy.
But don't do them at any higher layer than is possible; i.e., don't
build a framework or containers when what you really need is actual
functionality and logic.

4. Make it efficient.

If necessary, speed it up and make it smaller. But you don't try to
squeeze everything; figure out what's taking the greatest share of the
time, or the greatest share of space, or the greatest share of
whatever you're short on (network bandwidth, end-user patience, etc.).
Then economize there. This seems obvious, but when you're trying to
make things lean, it's tempting to start working about using
java.lang.Integer instead of int when your slow part is the SOAP query.

--------------

(Is this even right?)

Tuesday, January 15, 2008

Rule of troubleshooting: first, fix what you KNOW is broken

There's a technique I've picked up from programming: when you have a problem, fix what you know to be broken first. Further, fix the most obvious broken thing first.

I think this started with C programming with cc and gcc. When you compile your programs, it dumps out a slew of errors it finds. I learned that the first error listed might be the only true error; the others were just shown because the compiler got all confused by the first one. Often, when I fixed that first error, the rest of the symptoms went away.

This technique seems to apply to other domains too -- network troubleshooting, in particular. There might be a pile of symptoms and a few known problems, and it may be very difficult to explain all the symptoms based on the known problems. But these are complex systems. That means you can't easily see it all in your head. 

So if you have actual problems that need to be fixed, fix those problems and see if the problems go away

Sunday, January 06, 2008

Digital Photos: the next slides


When I was a youngster, my mom was our family's chief photographer.
For purposes of conserving money, she took photos on slide film.
Developing the slides, as I understand it, was significantly less
expensive than having prints made.

I have my own youngster now, and we're taking photos. Our primary
photo format is digital photos. They're stored in JPEG format on my
laptop hard drive. No, it's not a RAID. While I have taken backups in
the past, I don't have a current backup.

A computer typically lasts 3-5 years. And data is often lost when a
computer dies; often it's just that failure that prompts a purchase of
a new computer. The laptop could be stolen. The hard drive could just
fail.

The OS could go screwy and damage the files.

I could lose track of where the files are, even if they're still in my
possession.

There's a chance JPEG could become unreadable. There might be a court
ruling on some latent patent that makes it hard to find a JPEG viewer
in the future. (Surely, somebody out there has The Patent on
displaying digitally-encoded graphics on an LCD, or projector, or some
such.)

At least with slides, we know where they are. No, we don't have a
slide viewer of our own. The slides could be lost to a fire, or we
could just lose track of them.

With prints, as long as we know where they are, and don't lose them to
fire, we can view them.

I'm just concerned that by the time Oren is old enough to care, it
might be really very hard to show him photos of when he was young, or
when I was young.