We're hard at work finishing up Basecamp 1.0 scheduled for launch in "January". With just five days of integrity left in that promise, there's a natural sense of urgency within the development team. But when both designer and programmer are natural customers of their own product, it's incredibly hard to resist gold-plating — the continuous stream of tweaks and small additions.
Exploring the same arguments over and over again on why adding yet another little thing is the slippery slope that turns January to February is futile. In isolation, the importance of the single change always seem to rise above the concerns of the big picture.
This is of course an age-old problem with a vocabulary rich of colorful descriptions, such as feature creep, creeping featuritis, bad feature karma. But designers are rarely aware of software development history and terms while programmers tend to conveniently forget when it's their addition.
Our solution has been to allow enough creeps onto the todo list that the big picture revealed itself as significant. That led to the inevitable talk which obviously concluded: polish is superficial, shipping is progress. With that conclusion in mind, the whole teamed compressed all the arguments, agreement, and promise into a single word of distributed enforcement: "creep".
What awesome power can be held in such a little word. As I witnessed just yesterday in an plea for RSS support in 1.0 that had all both oodles of enthusiasm and an optimistic estimate. "Nice, but creep!" was the predictable response. It's reached the point where we'll prelude an attempt with "I know it's probably creep, but..." usually well-knowing that it'll be whacked. Wishful thinking die hard.