Cykod

Parking or No Parking? When complexity just isn't Worth it.

by Pascal Rettig posted Sep 21, 2010

One of the major issues with Specification-driven-design or Developer-driven-design is that you can end up in some insane places just because something "makes sense" on paper. A feature that someone might someday need might make a good bullet point on the back of the (now usually metaphorical) product box, but it won't necessarily add value to your product.

As Antoine de Saint Exupéry wisely noted: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." (From Civ IV, Engineering Technology :/ )

There is nothing worse in a piece of software than too many options that provide little value to the software. Sure, they are bad from the developer perspective because they weigh down the codebase and make it more likely to turn into a scary medieval labyrinth, with little-used and little-tested code-paths lurking like decaying zombies in the corners of your project ready to pounce and eat the brains of anyone bold enough to attempt to refactor (and I mean this quite literally)

From a user perspective, however, things are just as bad. Features add complexity, and complexity is the number #1 complaint I've heard from users. Apple has made Billions by reducing features and complexity (See: the Simplicty Era) People don't want to worry about things that aren't necessary because they hinder their ability to see the what's really important.

All of which brings me to an unfortunate parking sign that sit on Cross street in the North End (notice they've already iterated on the sign using tape):

At some point, when the city added the forth and fifth placard to the pole, do you think anyone realized what a cluster-f&*k that sign was? I'm sure they had the best intentions, maximizing the value of the spots by providing alternating visitor, resident and commercial (which is actually displayed on another sign) parking at different hours for different period of times - but the value of the spots is actually greatly decreased by the complexity of the options. People usually can't figure out what the heck is going on, so the spot is either occupied when it shouldn't be (and quickly ticketed - maybe that's the plan) or sitting empty when it's actually OK to park.

Here's a flow chart showing you whether or not you can park (click for full image):

 

In this case I see the city as the outside consultant brought into a software project looking for a way to prove their value. Parking in the North End is a valuable commodity after all, but the solution they came up with, while it might look good in a specifications document, makes no sense whatsoever when presented to the user.

Software gets built like this all the time, and it needs to stop. I think we're headed in the right direction, with user stories now driving a lot of development, but if you ever get ahead of yourself planning some great back-of-the-box features in your product, just remember the parking sign, and the fact that someone, somewhere signed off on it as a good idea.