Code Softly

Selfish features make your staff happy and efficient, but have nothing to do with helping your audience. Remember them? The people who are going to make or break you? The people for whom your site exists in the first place?

Here’s a few features I consider “selfish”:

1 - Content Management Systems (CMS)

CMS’s are great, and critical for creating new information for your audience. Keep in mind that you could read a book and learn to write HTML, or maybe even pay the geeky kid down the street to update a bunch of static pages for you.

Don’t wait for a CMS to start your site. Put SOMETHING up while you’re rigging the internals of your authoring tool.

2 - Analytics Dashboards

Dashboards are sexy. They combine lot of impressive looking charts and figures into one place.

Sadly, dashboards are time-consuming for developers to build and test, and people rarely look at them.

Try waiting until you find yourself saying “Boy, if we only had metric X, I’ll bet we could make 15% more”, and THEN ask for the report or dashboard. Remember, time spent on reports is time NOT spent on features for your customers.

3 - Rich Text Editors

This goes along with the CMS selfish feature. People want their authoring experience to be “just like using Word”. Reality Alert: authoring HTML is not the same as authoring a term paper.

Rich text editors almost never work. They create bloated, crazy markup that messes with page styles, have unpredictable image placement and layout, and pretty much cause more trouble than they’re worth. Consider markdown or a similarly humane syntax that helps the author out, but doesn’t try to candy-coat the reality of what they’re doing.

There are many more. You get the idea.

I’m not advocating that we never build selfish features, but it’s important to recognize them for what they are: indulgences to make life easier for you, and not for your audience.

“Avoid premature optimization” is a popular and effective mantra. It’s a defense against the temptation to worry about speed and performance before you even have a working feature. Sadly, this often ends up interpreted as “forget about optimization”, and that’s a big honking mistake.

Speed matters. The magic number has changed over time, but the basic rule hasn’t: the longer a page takes to load, the less likely people are to use it.

Too often programmers quote The Mantra and then neglect to ever optimize. The idea is to avoid focusing on speed too soon, but not forever.

The best way to avoid forgetting about performance is to make it a feature. When building your backlog, pop in a story that goes like this:

As a user I want the homepage to load in under two seconds so I can quickly view the upcoming concert schedule

That way, everyone understands the value of speed, and it doesn’t get sacrificed for more easily visible features.

Image by Mike L Photo’s Some rights reserved

At work we’re looking for a new tool to manage workflow, tasks, and status. We haven’t been thrilled with our current system, but decided to live with it until it became to painful and/or costly to keep around.

I think living with the bad tool has been instrumental in learning what we want in a great system.

There’s always a strong temptation to discard something that pisses you off and try something new ASAP. When you do this, you learn what you hate, but very little about what you value. You might go through three or four tools before you get a handle on the core features that mean the most.

Living in pain, on the other hand, cultivates wisdom. You start learning why you can’t stand the lack of a quality workflow system, how important project setup is, and if you care about how fast it is.

With a list of grievances, there’s little room for “well, that’s just, like, your opinion, man”, and more experience-based decisions emerge naturally: “Remember how much you hate that tiny text field?”. It’s much clearer when a good choice presents itself.

Once you learn these things, you can pick your next (and hopefully last) tool. Fingers crossed.

Photo by Noel C. Hankamer ;Some rights reserved

Ever spend more than 45 minutes trying to align three page elements in a horizontal row? Of course you have.

Like most developers, you refuse to use the table element for layout. The problem is that CSS stinks for horizontal layout. So we’re left fighting block and inline display rules, temperamental width issues, absolute vs. relative positioning, and browser quirks (wtf is the box model, anyway?).

CSS frameworks to the rescue. They let you do fairly semantic markup, have minimal sizes, are multi-browser compatible, and make it easy to align page elements.

My personal favorite it Blueprint, but there are a bunch of others.

Almost every software development deadline is movable. Even if the CEO of your Fourtune 50 company has promised via international press conference your product will ship August 1st, the deadline can move.

Of course, your CEO will scream at you and be pissed, the public might be disappointed, people may be fired, but if your company set the deadline, your company can move it.

Compare that to a deadline that is IMPOSSIBLE to move, no matter how much you or your company wants it.

If your product release is tied to a national holiday, astrological event, or similarly externally imposed temporal happening, be very careful how you build.

Be paranoid. Build, test, and deploy only the bare essentials. Start immediately. There’s always time to add on further enhancements once you have something live.

Need to build a home search site in time for a local leather festival’s parade? Start with a static HTML page that lists all the properties in alphabetical order.

Need a site that lets people track an upcoming NASA mission? Just publish a static timetable of the launch events. Build the interactive streaming video stuff once that’s up.

Having zero features at the deadline is utterly unacceptable, so get something greater than zero deployed ASAP. Remember that any number of catastrophes can happen between now and your deadline (the one you can’t miss), so get it out of the way.

This also has the nice side effect of acting as a kind of minimum viable product, and you can get early-users’ feedback to help drive the other features. It would suck to spend months building an augmented reality feature for 11/11/11 day, only to find out three people used it.

I’m pretty sure Facebook’s f8 conference this year was scheduled AFTER they had all their ducks in a row for the new Timeline and OpenGraph features. That’s pretty dang smart if you’re dedicated to quality products.

This year’s F8 conference wasn’t announced until about 30 days before it happened. That’s a little weird for a major tech event. Often they’re set up a year or more in advance.

I was puzzled until I started thinking about the pressure that must have been on the Facebook development teams to finish the features in time to have them ready for zillions of people to use the instant Mark finished his keynote. Then I realized what probably happened.

What makes the most sense to me is that Facebook finished Timeline and OpenGraph, and THEN scheduled f8.

Genius! No rushing at the end to cram in half-finished features. No shortening of the test cycle. It’s so much healthier to keep refining a product, and have someone watching to determine when it’s “done enough”, and THEN go scheduling announcements, rollouts, and other dramatic things.

I’ve noticed that when our family’s bar of Zest is reduced to a certain size, it becomes ineffective. There’s still soap in there, but it just doesn’t seem to produce any quality lather. I suspect the same is true of small software development teams.

A team of one or two programmers is small and nimble, but susceptible to external forces. If a team member gets sick, goes on vacation, or takes another job, your team is reduced by 50% or 100% for that time. That’s a lot. The remaining team member is almost certainly forced into some extremely inefficient task-switching, further reducing throughput.

I think it’s OK to dedicate a very small number of people to a task, as long as they’re part of a larger team with members who can help out in a pinch. Plus the team will naturally cross-train as they ask each other for help or advice.