Power Wagon Woodie

What a beautiful truck George Wellman has, in his 1950 Dodge Power Wagon, the only existing Campbell-body Woodie PW. Here is a link to some pictures I took during my recent visit to Traverse City, MI. George and Jill were extremely generous hosts, and I thank them.

Recently Spotted

Two sides of the same sign, on a church in Traverse City, MI.

I'm sitting in a place called "The Catch" in Traverse City, Michigan. This is a pretty cool town. Tomorrow I pay a visit to George Wellman, owner of the venerable (and only known remaining) wood-bodied Dodge Power Wagon "Woodie". I can't wait to see it, and meet George...


Posted with LifeCast

Sittin' in Starbucks waiting for the bank to open, and I thought I'd try a blogging app on my phone. A good way to use a lot of time, trying to type with my thumbs!


Geolocate this post

Posted with LifeCast

Driving big trucks

I recently bought an antique Mack tractor trailer, and in order to be able to drive it, I went to truck driving school. I now have a California Class A commercial license, and can drive just about anything except hazardous materials and tankers.

One of the main things about driving a tractor-trailer is knowing where your trailer is, and making turns so it doesn't crunch the stop sign and bicyclists along the way.  A long trailer is tricky to manage, and you have to swing wide on the turns, as I'm sure you've seen drivers do. And backing up a long trailer is no small thing.

Yesterday a "hook and ladder" fire truck turn left in front of me and I watched the guy in the very back skillfully driving the back end of the engine around the turn. This is not so easy to do, as you might imagine. But I found myself thinking about the guy driving in the front of the truck.

I can drive a truck with a 50-foot trailer, but the game changes, it seems to me, when there's another driver swinging the back end around. Much of it is good, since you don't have to take the turns so wide, but it also seems just downright weird, to take a corner with a 50-foot trailer and not have to worry about the back end of it! They call these "tiller trucks".

There must be an amazing amount of communication and trust between these two drivers.  I can't think of anything else that has two active drivers piloting the vehicle together as a team. Co-pilots of airplanes take turns, for example; it's not as though one of them flies the back end of the plane while the other flies the front.

Just another reason to admire fire fighters, I guess!

Nuts-and-Bolting

A friend in Australia used the phrase "nuts-and-bolting" to describe what I'm doing now, and I love it: .  There are a surprising number of nuts and bolts in the real world, and I've been using wrenches a lot.  In fact, a wrench slipped in my hand and I hit myself in the face the other day, and it made a perfectly semi-circular cut on my cheek bone.

Compared to the software world I've been immersed in for 20 years, this is quite a different world. If you have some bolts that are 3 inches long but you need 3-1/2", you actually have to drive to the hardware store and buy some.

I think what I miss most is multiple Undo, though!

Issues with iPhone

I bought an iPhone 3G yesterday.  Mostly because I may be doing consulting for a VC firm that likes mobile technologies and I wanted to know more about it. But despite having blogged before about how I don't need one, I do recognize the excellent technology in the phone.

There are a few things that totally bug me about it, though.

1. [This is a major flaw in Apple Mail.app too] when setting up a new Mail account, it insists on everything being perfect before allowing you to save the Account. I didn't remember the exact user name for my POP mail account on one of my mail accounts, and my only choices were to get it right, or cancel the whole thing, and lose all of the data I had already entered.  I have now entered this email account a total of four times, using the cheesy iPhone keypad, because of this ill-considered feature.  It should save whatever data I've entered, and let me fix the mailbox retrieval parameters later.  Or never.  Why should I have to be able to retrieve mail to set up a Mail account?  What if I want to send mail from my iPhone, but read the responses on my other computer?  Apple always thinks they know better than you/me/us, but sometimes they're just wrong.

2. I am a .Mac (now MobileMe) subscriber, and have been for years.  It all works fine, although on my iPhone it doesn't give me enough choices.  For example, I subscribe to a lot of calendars in iCal.  My family publishes and uses a bunch of calendars, mostly because iCal does not support multi-user calendars (e.g. a Family calendar that multiple people can edit).  Anyway, only the calendars that I have created show up in my iPhone calendar, and I have no way to subscribe to others, or Sync the ones I'm already subscribed to.  Makes the entire iPhone calendar *useless*.  I have looked through all the preferences I can find, on MobileMe, on my Mac, in iCal, and on my iPhone.  I don't think this can be done.

3. Sync from Address Book to my iPhone seems not to work very well.  It synced my list of contacts initially, but a lot of fields were missing (such as phone numbers).  No amount of pushing, cajoling, or Preference-setting seems to fix this.  It kind of makes the Address Book *useless* too.

I did find the preference  in the iPhone to change my signature, and dutifully changed it to "sent from my schmyPhone" :)

iTunes missing features

iTunes has evolved for about 8 years now since it was acquired from Casady & Greene.  For some reason, it has almost no new features for enjoying music.  I can't imagine why this is the case.  I'm sure the authors have seen the movie High Fidelity, which came out in 2000. Classifying and sorting music is a primary part of the experience.

I still can't sort my music by artist's last name in iTunes, which seems like the most basic and most desirable feature you could put into a program like this. It is how almost everyone sorted their music before computers came along. Why is this feature not available?!.  I'm sure the reason is that the underlying CDDB database doesn't have separate fields for Last name and First name, instead having only Artist.  But come on, for something this important, with many hundreds of millions of dollars of market pressure behind it, this is a very easily solvable problem.  Get on the phone, call up Craig Palmer over at Gracenote, and get it done.

There are no user-definable database fields. For example, imagine if you could use Genre for your own purposes, to put something like "mellow" or "road trip" or "dance" or "memories" other classifications that mean something to you, but aren't necessarily generalizable. This would be about 3 hours work for some programmer to add some fields to the database, and let you use them for searching, organizing smart playlists, etc.

There should be a "similar" axis that can be used to relate songs to each other.  Imagine a play similar menu.

Play all versions of this song.  I happen to have almost every recorded version of "Georgia on my Mind", and short of making a playlist, I can't play all of them one after the other.

Play songs I like but haven't heard for a while.  iTunes knows the most-listened to songs, and ratings; seems like this should be easy enough.

All in all, I think iTunes is a big disappointment for organizing and listening to music.

Engineering Process

[I found this document in my archives from a little while back and thought it would be useful to somebody out there, so I'm posting it.]

Introduction and Philosophy

You have a small team of people who are highly motivated and work well together. The right process for this group will be one that allows and encourages the organic development process while preserving clarity of purpose and minimizing surprises.
 
The big ponderables are: “what exactly are we building?” and “when will it be done?” and, to a lesser extent, “who’s going to do what?”

Schedules and Deliverables

One of the hardest things to do in building software is to accurately schedule a release and then hit the schedule. There are various reasons for this but the primary one is simple: shooting at a moving target.

It is easy to suggest that nailing down a specification and building to the specification is how to avoid schedule slips and shooting at a moving target. However, that is unrealistic for almost any organization except those that are large enough to be able to absorb errors of large magnitude.

A better philosophy for a startup is to understand that there are two variables and that either may be changed, and that they interplay. The two are delivery date and features/functionality. This seems obvious on the surface, but it is critical to manage this willfully rather than have it sneak up on you.

Axiom: if you fix the delivery date, the functionality becomes elastic and indeterminate. If you fix the feature set, the delivery date becomes elastic and indeterminate. It is best to fix one or the other, and not to let both of them float.

Alpha / Beta / Bake / Ship: A Convergence Model

Developing and shipping software is a bit like cooking. You plan a menu, buy ingredients, and try to choose a time when dinner will be served. Some things need more preparation than others, but in order for all of it to come together at a prescribed time, you must commit sooner or later to each dish, when to start the final preparation, and how long it is going to take. The dishes, preparation, and use of burners and utensils must converge on the final time. It is as much art as it is science, but it is possible to reproduce it scientifically. Software is like cooking in the sense that the more times you’ve prepared a dish, the more accurately you can predict how and when it will be done. And the more people who are in the kitchen, kibitzing and drinking wine and chatting with you, the more inaccurate your estimate will be.

In order for software to gel into something you can give to your customers, there needs to be a period of time, often called bake time, where new development stops and bugs are fixed and real regression testing is done in earnest. The duration of this period varies with the complexity of the software, the scope of the changes that have been made, and how it is delivered (burned on CD and replicated, pushed to a web site, etc).

For convergence of a large project (i.e. a major release, not a minor feature or bug fix) it is good to separate the convergence into two phases, usually called Alpha and Beta. These imply both a milestone and a period of time. The milestone is the beginning of the period of time. A product is said to “hit Alpha” when the criteria for Alpha are met, and the Alpha period is then entered. At the end of Alpha, when the product meets the criteria for the Beta milestone, it “hits Beta” and enters the Beta period. Often there is a third, shorter period following Beta which has various names, like “golden master” phase (coming from the development of software which is burned onto a disc) or simply the “bake period”. These terms are overused and poorly understood, but a good working definition of the milestones and phases
is:

• Alpha:  All features are in and working to the point of being demonstrable. That is, you could demonstrate them to someone else. To properly meet an Alpha milestone all aspects of a feature must be in and working, not just the fun/interesting part. For example, if a feature has three separate states/interfaces based on whether a person is a site visitor, a logged-in user, or a content owner, then all three of these states must be working. Bugs are tolerated, as long as a feature can be demonstrated to work at least once. The Alpha phase is not a time to finish features, it is a time to fix bugs and re-engineer any parts of a feature that can’t be made to work reliably, to squash bugs. This is important because some bugs result from actual design flaws, not just coding errors, and the bugs can’t be truly fixed without re-engineering. The Alpha phase differs from Beta primarily in that such minor redesigns are expected, and encouraged. Do it now, rather than sweeping the bugs under the rug and hoping that the design holds. Do not introduce new features, no matter how tempting. To do so will revert the product to pre-Alpha state.
  
  
• Beta:  All features are working smoothly and there are no major bugs that might suggest design flaws or major effort to fix. The Beta phase is spent polishing user interfaces, fixing bugs, and enhancing the user experience. Do not introduce new features, no matter how tempting. To do so will revert the product to pre-Alpha state.
  
  
• Bake Period: To mark this milestone, and enter this phase, you stop changing the source code. The expectation is that you can ship what you have. You test it, and test it some more, and find bugs. Resist the temptation to fix every bug you find and spin a new release. Every change to the source code resets the bake period. Think of it this way: sooner or later you will quit changing it and you will foist it on your users. In the bake period, you are pretending that you have shipped it, and you are simulating real use. Some number of bugs will come up after you’ve shipped the product, and you may or may not choose to fix them, depending on severity. But the bake period is not effective if you continue to fix bugs. It is simply a simulation of holding your breath and hoping there aren’t any barn-burning bugs in the software. If you find a barn-burner, and you all agree that the barn really will burn down if you don’t fix it, by all means fix the bug, and reset the bake period. Don’t omit this important step of resetting the bake period. You are, once again, pretending it is live. Each change, no matter how minor, violates that.
  

For a full-blown application I would suggest the following (minimum) durations for each of these phases:

Alpha: 4 weeks
Beta: 4 weeks
Bake: 1 week
 
This means that you quit adding features 8 weeks before you ship it, and you spend 4 weeks tweaking and improving the user experience of features that you’ve chosen to implement.

Using the Model

I once took a class in Marksmanship at the college I went to (University of Wisconsin) just for the hell of it. It was a zero-credit class, and officially was part of the ROTC program, though it was a very radical/pacifist school when I went there. Go figure. Anyway, a key takeaway from that class was as follows. When you hold out your arm and point a gun at a target, you should let your arm extend as naturally as possible. If you need to adjust left or right to hit the center of the target, you don’t move your arm, you move your feet. You arrange your whole body into a shooting position, then adjust your whole body toward the target, not just your arm. This is an amazingly good metaphor for all kinds of things.

If you adopt the Alpha/Beta/Bake/Ship model for developing and shipping software, it is important to think of the whole model as your whole body (to apply the metaphor), and if an adjustment is necessary, adjust the whole model, don’t try to hack/fake/adjust one part of it, or throw the whole model out the window.

It is a good idea to spend some time specifying your own criteria for each of the milestones, so you can all agree on whether or not they’re met. I’ve offered my own definitions (“feature-complete, all features demonstrable”, etc). Your mileage may vary. It is also important to establish the durations of your phases, though they can be adjusted (see below). But decide on milestone criteria and phase duration, and apply them. The model will reward you.

Note: this model, although it seems formal and big-company-ish, is really just a simple way to force yourself to really look at your software at each phase, and apply criteria to convince yourself, through measurement, that you really are where you want to be. You can fool yourself if you want to, but software is a bit like dieting: if you never step on a scale, you can pretend to be any weight you want, but if you really want to make progress, and understand honestly where you are, step on the scale every day. It won’t change what you weigh, it will only let you know the truth of what you weigh, removing the human temptation to fool oneself.

Adjusting the Schedule

Using the model just described, and the concept of adjusting your feet, not your arm, there are a few ways to adjust without throwing out the model.

Phase Adjustment:  Adjust the amount of time spent in each of the Alpha, Beta, and Bake periods, to reflect the nature of your development, testing, and anxious users. This is an important and flexible aspect of the model. The duration of these phases is up to you. It is also
important to note that since criteria are applied to each phase/milestone, it is possible to skip a phase completely. I’ve seen it happen. Software occasionally meets both the Alpha and Beta criteria at the same time, and you can skip over the Alpha period. This might result in your being actually ahead of schedule if the remaining phases hold. This is rare, but achievable. Resist the temptation to celebrate by adding new features.

Resetting Milestones:  This is difficult, but necessary. If you add a feature, reset your process
model to pre-Alpha state. You can accelerate through the milestones/phases if the criteria are met, but it’s critical not to throw the whole model out the window just because you’ve decided to add a feature. “To add features is human; to reset the model to pre-Alpha, divine.”

Again, stick to the model and it will reward you. It is a discipline, but it is important to note the difference between a milestone and a phase. When you reset because of a new feature, you may be able to sail through the phases more quickly because the change is small, and your engineers are brilliant and got it right the first time. But it’s still good to re-apply your criteria and test and make sure you’re still good.

Using CVS

CVS is your friend, believe it or not. It records the exact state of your software and supporting files, and will give them back to you at any time of your choosing. It also tracks changes so you can assign blame, or review changes, or move backwards if need be.

The right way to think of your software is that there is “one true version” and that it is the one that is currently top-of-tree in CVS. If you embrace and use CVS it, too, will reward you.

If you modify a file, always do it by first syncing with CVS (e.g. do a “cvs update” first to make sure you’re working from the current version of all the files). Then make sure to check your changes in directly from the working copy. Do not copy files out of the CVS sandbox and then copy them back after a ‘cvs update’.  You will stomp somebody else’s changes this way.  Just work “live” on a CVS sandbox copy at all times, and commit the changes when you’re ready.

Scaffolding

It is important that anything you commit to CVS be internally and externally consistent.  The paradigm is: don’t break the build! Don’t make any changes that will cause existing features not to work, unless the changes are either commented out or conditioned on an “ifelse” that is false. That is, you can have “if ( 0 ) { your_stuff(); } else { current_stuff(); } and set the “0” to “1” while you’re working on it, but leave it at “0” when you check it in.

While you’re working on something there will be temporary states and what I think of as “scaffolding” that will be removed later, but makes the project safer and provides fewer surprises while it is being worked on. Consider your scaffolding carefully to avoid committing anything to CVS that is not production-quality, that you wouldn’t mind making its way into a
live version of the software.

Communication: What Changed?

Effective communication between Engineers and “everybody else”, especially testers, is important to good quality management. “What changed in this build?” is a familiar refrain in any software company. 

It’s hard to remember what you changed, and why, when you’re working on software. Writing release notes after the fact is unwelcome and error-prone: you just forget. There are various ways to mitigate this. The methodology that I find works best works by side-effect of using CVS
effectively.

Imagine that you are an engineer and you spend 3-4 hours working on the software, fix a couple of bugs, half-implement a new feature, add some comments to the code. You feel that it’s time to commit your changes to CVS. What do you do?

CVS Diff:  You type “cvs diff > changes.txt” and you take a look at what you changed. You look through the diffs to see exactly what you changed. Sometimes there will be something there that you forgot to remove (scaffolding). Sometimes there will be a bug-fix that you forgot about. Sometimes it will just be just as you thought. But this is an important step in software development, to diff your changes before you submit them. It’s a final check for accuracy, a memory jog, and just good practice. But keep the diffs either with copy/paste or some other method.  You’ll need them later.

Checkin comments:  Type in a few lines when you commit your changes to CVS to explain what the changes were. Keep a copy of this too. You’ll need it for the third step.

Send Email:  Send an email to your “dev” alias or make up a new one for “code changes”. Send the text of your CVS comments, and the text of your CVS diffs. Add a Cc: copy to the code-change wiki for extra credit (it will log all changes for future perusal).

The discipline of reviewing your own changes, summarizing them, and sending an email to whomever cares will make for ad-hoc release notes and will add an extra valuable step to the process. Not only will you review your changes one last time before committing them, it gives your team a chance to review your changes too, to see the magnitude of changes (if it is in the
Bake Period, for example, when you’re not supposed to be changing anything), to provide an extra set of eyes to help spot bugs/issues, and just to give people that sense of “what changed?”

Testing / Versioning

There are as many approaches to testing as there are QA teams. I won’t recommend any particular methodology. What I will recommend is strong versioning.  Make a visible version number somewhere in each build, and make sure you change it every time you change the software. Don’t be lazy. My mottos is “integers are cheap.” Use them liberally. Add one to the version number at every change. Don’t ever let two slightly different versions of the software be indistinguishable by a tester, validator, or engineer. Then make sure all bug reports accurately report the version of the software in which the bugs are found, and make sure the Engineers always mark each bug with the version in which the bug-fix is expected.

Conclusion

The building blocks of a good process boil down to these things:

Alpha/Beta/Bake/Ship:  Agree on your milestones and phases, and stick to them religiously. They don’t have to be big, dramatic things. Just be clear about what you’re trying to do, and when you’ve done it. Don’t lie to yourselves.

Trust and Use CVS:  CVS is your friend, and if you build your process around it and never deviate, you will always have repeatable, surprise-free releases.

Stick To It:  Adjust the process (move your feet), change the milestone criteria, reset the ship date, but don’t abandon the model. Make it work for you, in a way that makes sense to you, but stick to it. It will reward you with a smooth, surprise-free development/release process.

You can’t avoid bugs and bad software. No process can save you from that. But you can avoid silly mistakes, human error, and surprises, and you can feel good that you are releasing what you’ve tested, you’ve built what you thought you built, and nothing snuck in around the edges to ruin everything.

new iPhone - my rumor mongering

I don't like to participate in the Apple rumor mill, and given more than 5 years since I worked there, my contacts have gone cold, but given the high level of secrecy, something big must be up.

I'm thinking video conferencing.

National Inventor's Day

Today is the anniversary of National Inventor's Day (in the U.S. at least). It is also Thomas Alva Edison's birthday. This holiday was created in 1983 by Ronald Reagan, though if you read the proclamation carefully, it was just that day in 1983, not in fact a recurring holiday. I choose to think of it as Edison's Birthday and therefore recurring.

"Almost two hundred years ago, President George Washington recognized that invention and innovation were fundamental to the welfare and strength of the United States. He successfully urged the First Congress to enact a patent statute as expressly authorized by the U.S. Constitution and wisely advised that ``there is nothing which can better deserve your patronage than the promotion of science . . .'' In 1790, the first patent statute initiated the transformation of the United States from an importer of technology to a world leader in technological innovation.

"Today, just as in George Washington's day, inventors are the keystone of the technological progress that is so vital to the economic, environmental, and social well-being of this country. Individual ingenuity and perseverance, spurred by the incentives of the patent system, begin the process that results in improved standards of living, increased public and private productivity, creation of new industries, improved public services, and enhanced competitiveness of American products in world markets.

"In recognition of the enormous contribution inventors make to the nation and the world, the Congress, pursuant to Senate Joint Resolution 140 (Public Law 97 - 198), has designated February 11, 1983, the anniversary of the birth of Thomas Alva Edison, one of America's most famous and prolific inventors, as National Inventors' Day. Such recognition is especially appropriate at a time when our country is striving to maintain its global position as a leader in innovation and technology. Key to our future success will be the dedication and creativity of inventors.

"Now, Therefore, I, Ronald Reagan, President of the United States of America, do hereby proclaim February 11, 1983, as National Inventors' Day and call upon the people of the United States to observe this day with appropriate ceremonies and activities.

"In Witness Whereof, I have hereunto set my hand this 12th day of Jan., in the year of our Lord nineteen hundred and eighty-three, and of the Independence of the United States of America the two hundred and seventh.

Ronald Reagan"

Unfinished Projects

I recently have been tackling a long backlog of unfinished projects (and starting a few new ones, of course). I've noticed a pattern in how I do projects that I suspect others have as well. You identify what you need (1-1/2" pvc pipe, a u-joint, two couplers, two elbows, and some pvc glue), measure a few things, and go to the hardware store. You come home and set the bag of parts down in the garage, next to...

...and here's the problem: you set it next to 7 other bags from the hardware store, each of which contains the exact ingredients (on a good day) to complete one project. But if you leave stuff in the bags, you'll never finish the projects. Seems obvious, but even if it's "just until tomorrow", there's something opaque and unnoticeable about bags from the hardware store. You just don't see them after a while, and you can't even remember sometimes if you actually bought the stuff or not. Once or twice I've come home with a *second* entire bag of the same stuff, months later, for the same project. I feel pretty foolish when I discover the original bag.

I've looked inside a bag from Home Depot, said, "aha! that's where those hinges and lag screws are..." then literally 15 minutes later, had to look for them all over again. "Which bag were they in? I forget where I saw them." It's amazing how good those flimsy plastic bags are at hiding things from you.

So I've learned to take things out of these bags as soon as I get home from the hardware store. Even if it means piling the stuff on the work bench. At least then it's in the way, and will get put away more quickly than a plastic bag sitting on the floor. Literally putting the ingredients away, even if the project will be completed tomorrow, is a good plan. File the 1-1/2" plumbing fixtures in your plastic box labeled, you got it, "1-1/2 inch plumbing". I say plastic box because I have come to believe it is the right way to store almost everything. You can see into the boxes. Nothing can hide from you. You can label them too, but you don't really need to: they're see-through! What a revolution in storage!

I'm a pretty organized guy, and I'm getting even better, since I'm focused on it. I'm setting up a new workshop and taking the time to organize it as efficiently and thoughtfully as I can. It's a challenge, but it's a fun challenge. It's amazing how much time it takes to think through and implement storage systems and workshops....

Recency Illusion

I subscribe to a bunch of magazines; one I especially like is New Scientist. There was an article in there that I read a couple of days ago describing what I have noticed but never named: the recency illusion.

When something that you have discovered recently you assume is new to everyone is an illusion. In the software world I used to call a variant of this the "most-recently-discovered bug syndrome", which was the tendency to assume that a bug you just discovered is the most important one of all. It's actually the other way around, with bugs: if it took you this long to discover it, it must be relatively obscure, right?

Perhaps like everyone, I am susceptible to the recency illusion. In fact, in a very circular sort of way, when I set out to blog about this, I thought I should dig up a reference to the New Scientist article to link to, assuming that this was a new term that nobody would be familiar with. Ha! I set out to determine how new the phrase "recency illusion" is, which led me on a labyrinthine journey through Google links. One search result suggests that Arnold Zwicky coined the term in 2005, though vexingly, clicking on the link in the search results reveals no such mention; the abstract seems to have been edited.

But this article in the Language Log blog is great. It describes the "Cupertino effect" which you will just have to read to understand. What a great journey through linguistics with my morning coffee!

Copy Protection punishes honest people

I worked at Adobe Systems first in 1985, before PageMaker 1.0 was available. In those days software was copy protected through various means, all of which were nefarious. Aldus used to drill holes in the floppy disks and the installer would look for the bad disk sector to correspond to it.

Copy II Mac was a free utility that defeated copy protection easily. If you wanted a free copy of PageMaker, or any other app, you could get one.

<rant>
22 years later, the situation is different, but the outcome is the same. If you actually buy a legal copy of software, you are either inconvenienced or completely incapacitated at least once by the copy protection (now called "activation"). I have a legal copy of Adobe InDesign CS3, and my computer freaked out so I bought a new computer and transferred all my stuff to it. I launched InDesign and it told me I needed to reactivate the software, but wouldn't let me because my old (dead) computer was still on the list. Instead of a nice easy way to say "transfer one of these licenses to your new computer" maybe with a nice list of my activated computers, it just told me I couldn't do it, and needed to call the 800 number. I've called twice (it's 9:00pm on a Friday night), gotten no one on the phone, but I've entered well over ONE HUNDRED digits on my phone accompanied by many # keys to confirm that no, I can't activate this computer.

They give me 5 days to solve the problem, which is better than shutting me down. But they put the onus on ME, the paying customer, to do all the work of reading or typing in all these god-forsaken keys into the phone or the activation screen. They are punishing me, again, for being a paying customer. And if I don't get this resolved in the next 5 days, on my time, calling and entering numbers and waiting, then I can't use the software that I paid for. The frustration level is very high.

The true criminals have a much easier time of it: they just go get an illegal key off the internet somewhere and away they go.

For a while there, maybe a good decade, everybody had done away with copy protection because it was well known that it punished the wrong people. It's come back, and it's as bad as ever. I guess there's a new generation of people now who really do believe they can prevent software piracy, and all they have to do is get the customers to enter 30-digit numbers. They're wrong, as were their forebears. I don't know if I can wait for the next cycle of anti-copy-protected software to come along.
</rant>

GMail security (or lack thereof)

I have a GMail account. I don't use it. I don't like Google's policies about keeping/filtering email. But I have a GMail account. Maybe one day I'll use it. They sort of force you to have one to do a lot of things, such as blogging on Blogger, which this blog is. Sigh.

Anyway, today I logged in to my GMail account, out of curiosity to see if I had any mail. I have a WHOLE LOT of spam, which is what prompts this blog post. 738 messages, as you can see in the screen shot to the left.

I have not given out my GMail account to anyone. I never send mail from that account. I use it only to log into Blogger, to save maps in Google maps, etc. So really the only entity that has my GMail address is Google. Evidently, they have been hacked/compromised or else they're selling my email address to the spammers directly. How else would this email address wind up on spam lists?! I tried searching for it (my address, and no, I'm not posting it here for spambots to harvest). There is no way I can think of for a spambot to have gotten this email address except through Google itself.

Kind of scary. Now I'm really not going to use my GMail account.

Sky divers die in plane crash

It strikes me as extremely ironic that the plane crash today was 10 members of a skydiving company, all of whom apparently were in the plane when it hit the ground. You'd think they'd jump out, with parachutes, wouldn't you?

iMovie 08 doesn't cut it

I'm the guy who created the version version of Apple's iMovie back in 1998 so my thoughts about the new iMovie might be biased. On the other hand, I know a lot about software and movie editing.

Apple tossed out iMovie this year and rewrote it from scratch. They got it wrong. The new iMovie... well, it sucks. I still have friends on the iMovie team (for a little while longer, at least), but I don't care. I'm going to blast it anyway, as the piece of useless eye-candy junk that it is.

I have a lot of specific reasons as to why that is the case. It's not just the missing features, or the fact that it can't even open an existing iMovie project, which is Cardinal Sin #1 in any advanced version of a project- or document-based software product.

I did a brief test run with the new iMovie, which I will heretofore call "iTube", because it shouldn't really be called iMovie. I put it through some quick paces, found an inordinate number of bugs, and gave up. But I remained silent, because I had a feeling that I was just being negative since they had just thrown my baby out with the bath water.

But today my daughter, who is 11, and who has a brand new iMac, asked for help with iMovie, since she knew I had created it. I saw that she was in fact using "iTube", and she was confused. She had shot some DV footage with a friend and wanted to edit it. I watched. As user experiences go, it was an unmitigated disaster. Georgia, a competent 6th grader, and her friend, a high school sophomore, could not do anything useful with the program. They had trouble importing the footage, because the "Automatic" mode simply didn't work. An uplug/replug of the camer and switch to Manual mode fixed the import. But that was just the beginning of the issues. There were an incredible number of individual clips, or "Events", since the girls were trigger happy in turning the camera on and off. They couldn't figure out what they were supposed to do, what they were looking at, or even how to "play the movie", which is of course the first thing you want to do after you import footage.

The first thing I noticed is that you simply can't "scrub" through a movie any more. The clips are arranged with carriage returns every so many clips, instead of in a linear fashion, so you simply cannot drag the cursor through the entire movie, because there's no way to navigate through one of the carriage returns (going from the far right end of one line of clips to the left of the next line of clips). The "Skimming" feature goes from novel but useless to annoying in about 5 minutes. It is activated simply by mousing over footage, so as you move the mouse around the program, the screen is constantly moving around on you, moving your point of reference in the movie, and pissing you off. There's simply no way to navigate through the footage!

I have heard the argument as to why the new "iTube" was necessary. Editing movies is too hard. Nobody does it. It needed to be simplified (again). This is all true. But it's not the editor itself that was or is the problem. It's because video is a time-based medium; therefore it takes TIME to edit it. There's no way around that.

Consider this... You've shot 1 hour of video footage on your camera. You come home and decide you want to make something out of it to show your friends or family. It takes 1 hour to import the footage into your computer. It takes another hour to watch it through once. If you stop, start, and enjoy it at all, it'll take you more than 1 hour. If you do NO EDITING at all, and decide to burn it straight to a DVD, or upload it to uTube, it will take you another hour in production time. You're THREE HOURS into the project and you haven't done a single edit. It's my contention that, if you're going to invest hours in just getting the footage from one place to another, and you don't edit it, you're missing the fun part. To scrub through video footage, play snippets, cut out the bad parts, pull it together into something presentable, is fun. Yes, it's time consuming, but it's fun, and rewarding.

The whole premise of "iTube" seems to be that you should short-cut the editing down to simply arranging clips and maybe throwing in some music, because, as the story goes, it was too hard to do that before. Well, after almost 10 years of people loving iMovie and making some pretty amazing movies with it, I have to disagree that it was too hard to use, and that was what was making people not edit their video footage.

Back to my critique of "iTube".

There's no timeline view, which on the surface seems like a "power user" feature. It is. But since video is time-based, if you're even a little bit interested in editing it, you start understanding the timeline and using it. If you're adding music or sound, it's critical to be able to operate in a linear time-based view. There's no way around it, I don't think. Just removing the feature isn't a way around it.

The idea of an "Event Library" is a pro feature. It doesn't map to the way families and amateurs create and reuse video. A clip/event library presumes that you have a lot of beautifully-shot, well-lit clips that can be rearranged to tell a story, or to compel people to vote for you in the Oscars. If you have a 3rd Birthday Party on one DV tape and a Trip to Yosemite on another, are you really going to love all that footage being in a Library so you can re-use it to make your masterpiece of cinema. No, you're not.

The "iTube" interface is very cluttered. There are a whole bunch of rectangles with unclear purpose, a lot of thumbnails and pieces of video everywhere you look, but no clear sense of what is your "movie" and what is not. Gone is the simplicity of One Big Window showing your movie, and a simple list of clips that comprise that movie. How is this new interface "simpler" or "easier to use" or "better"? There isn't a single thing to recommend it, and it violates all sorts of basic principles of Human Interface Design.

There is a tool bar in the center of the window (now there's innovation!) with commands that loosely map to menu commands, as all toolbars do, but you can't customize the toolbar, which has been a toolbar staple for about 15 years now. Nor can you figure out what any of the icons mean without the tool tips. Icons were supposed to be superior to text menus, but in this case I'd rather just use the menus. The first icon in the list, one that you instinctively mouse over to see what this new app is all about, says, "Add Selection to Project". The next one says, "Mark Selection as Favorite". Ummmm, okay, whatever. What selection? What project?

My favorite icon/button is a double-arrow that looks like a recycling icon that says "Swap Events and Projects". This lets you customize that one aspect of the interface, oddly, since no other aspect is customizable. It also suggests that Apple is not confident that the Events and Projects rectangles are in the right place. Why would you make it so easy to swap them? Why would you use a very prominent button in the user interface for something which you should probably never do, and at best will do once in the lifetime of owning the program? It's a fricking preference, not a major button in the interface.

The whole thing is incredibly poorly thought-out, hard to use, annoying, and, at the end of the day, not really a movie editor at all.

This app should have been called iTube 0.8, not iMovie '08. It's certainly a 0.8 app, not a 1.0 app, and it's certainly not iMovie.

Tesla Motors spotting

Today I spotted a prototype Tesla car up on Skyline Blvd. I had rushed over to talk to whoever it was, but it was clear that an interview was in progress so I didn't interrupt. The car looks very cool when you're next to it; a little smaller than I had imagined, but cool.



The best part was when the truck/trailer that was hauling the car up to Skyline stopped to refuel. Something very ironic about a Tesla vehicle stopped at a gas pump.



I asked the guy if I could buy what he had in his trailer, but he said it was an "unsaleable" prototype. Too bad.

I am a huge fan of Tesla Motors and can't wait for them to succeed!

Brilliant Civics

Saw this sign last night in Redwood City. It's more jarring to look at than the average yard sale sign, so I'm not sure they're making forward progress here.

"Redwood City Sign Ordinance 3.114 (This sign is exempt)"

iPhone schmyPhone

Everybody seems to think that since I worked at Apple I'm a big fan of every product they've ever made. Wrong. Though I can see why one would think that, since a lot of Apple customers are in fact zealots.

For the record, I'm a big fan of the XServe and almost everything that Bertrand Serlet and his team come up with. The OS is fantastic.

But I don't like the iPhone. I shouldn't say that. I just don't happen to want one. It's fine and everything, and I'm sure it's better than a lot of sucky phones out there. I also don't happen to want a Blackberry, and there's a lot of overlap between what an iPhone will do for you and what a Blackberry will do for you. Or do to you, depending on how you look at it.

The reason I don't want an iPhone is the same reason that I carry a Buck pocket knife instead of a Swiss Army knife. I hardly ever need a can opener or a saw or a teeny pair of scissors, and all they do is make the knife harder to use.

What I want is a phone that does *not* surf the web and does *not* process text messages or email messages or anything else, but is a *great phone*. Sorry, but the iPhone doesn't even come close to being a great phone. It's too big, it's not ergonomic for holding on your shoulder while you talk, and the shiny screen gets all greasy when you hold it up to your ear (lots of other phones share tehse problems, of course, which is why Steve Jobs proclaimed that people "hate their phones". True. But the reason we hate them is that they suck at being phones, not because they suck at being web browsers. You solved the wrong problem, Steve, though all the Gadget Phreaks in the world will need to have one, and the Crackberry people will lust after them, and all that.

For my part, I carry a 17" laptop for web/email and it beats the pants off a tiny screen. And I carry a Buck folding knife, which is a beautiful single-purpose machine, and anybody who knows me will tell you that it comes in handy all the time, and it's always in readiness in my pocket because it's small and does only one thing. And I'm still waiting for a great phone. In the meantime the Samsung flip phone I carry isn't bad.