Lipstick on a pig

If you’ve ever seen one of my project plans, there’s a chance you’ve seen a task at the end that says Add pretty. With good use of stylesheets, you can radically improve — or damage — the look of a website even after all the coding and most of the testing are done. A different person or group with a different skill set can take over from the programmers and work some magic with little interaction.

You might think, based on this, that other parts of development can be pushed to the end after “real” development is done. You’ll know someone was thinking that when you see a task late in a project plan that says “Add fast”. This is usually a sign of excessive specialization. People think that they just have to get the user interaction right and leave performance tuning to someone else.

I suppose I can live with the idea that there will be some performance tuning that’s best done once everything else is complete. And on some projects just throwing more hardware at the problem is cheaper than a programmer’s time to fix it. But actually improving the performance of an application is hard, and the changes pervasive.

Another side-effect of excessive specialization, one that always raises the brown flag, is when I see “Add security” at the end of a plan. It’s simply inexperience that allows anyone to think they can graft a security model onto a codebase after the fact without significant amounts of rewriting.

“But this is a quick hack, and we only need the numbers for this one meeting.” Sure, a report you’ll only ever need once. I guess such a thing could exist, but I’ve never seen it. In the first place, nothing lasts as long as a temporary fix that works well enough. And in the second place, many (most?) large, successful products started out as small, successful products.

End/begin dependencies look really great on a Gantt chart. Activities that invite and incorporate feedback don’t look so neat and clean. Treating security as something that can happen to a product after it’s already done is no better than … well, see the title of this post.

Design = function + aesthetics

Ask your local programmer if he knows how to design user interfaces and invariably he’ll say he does. Go ahead, ask. I’ll wait.

You’re back? Good. Now go look at the new iPhone. Has your guy ever made anything remotely that cool? Unless you’re reading this from Cupertino, odds are he hasn’t. The UI is more beautiful and, as near as I can tell from the demo movies, more usable than any other phone or music player I’ve seen. But I wonder, how much of the perceived usability is a response to the beauty?

It’s becoming conventional wisdom that you don’t want to make the demo look done. Excessive visual polish early in the process not only limits the feedback you get to comments about the superficial details, it also suggests equally finished interaction with the system. It literally makes it look like it’s doing more than it really is doing.

I’ve avoided this problem in my career by not being very good at graphics, and avoided realizing that by not working with any real visual artists to compare my work to. Yes, I used to think I was good at it, just like every programmer. Eventually I realized that consistency and predictability were a poor subset of what an artist can add.

Now, whenever I make up a project plan, there is a task at the end for “Add Pretty”. And my name isn’t on that task.