Always be finished

I’ve been living on a building site for a while, at home and at work. The work at the office above ours was ambitious, chaotic, noisy, messy and overran. It was a challenging project, turning a “derilict” into a funky new office.

Home was a simpler proposition, a greenfield site, with a well tuned team putting up a batch of similar houses. Each house in the project was a clear finishing point. The work was completed on or near budget, although there have been many bugs in the finished product. Nothing to break the deal, but enough to be annoying, and a few that need serious attention before things get worse.

The most interesting thing for me however was complete the overall project looks. At each stage the customer perception is paramount, so roads and car parks are built and finished in places where in a few months they’ll be ripped up to put houses on because that’s the most central place to put the marketing suite so customers can see their house quicker.

And the perfectly manicured lawns at the show home will be ripped up to build a driveway for the garage. And the landscaped street gables get cut back to move the marketing suite. But at each stage there’s a clear “here’s what’s being built” and “here’s the rest” even when what looks complete is not the final vision.

The perception even extends to certain rules for residents to ensure consistent façades and a complete presentation, with no unsightly trade vans, for the entire site until the last one is sold.

When you build software, how finished do the “temporary” solutions look to the customer and the developers. Do they look hacked on, unreliable and in desperate need of a bug fix, or do they look finished and smooth to the end user, with a few backlog tickets describing what it really should do. No hint to users or competitors that something is about to change.

It’s not enough for everything you release to be complete and tested. If users can see the cracks, it will colour their impressions. Fix the snags and delight your users.

Advertisements

4 thoughts on “Always be finished

  1. A good post. One other thing this analogy illustrates… All of the temporary parking lots and artifacts are carefully designed not to interfere with the permanent structures that are build. It would be horrible to have to demolish Real homes when they want to take them out…

    Yet look how many times removing the artifacts from software has an impact. Rework, Regression Bugs, et. al….

    Liked by 1 person

    1. Excellent point. Temporary features should be easy to remove. Only on the edges (the ux classic “sign up to show interest” email input for features that don’t exist), or abstracted behind an interface and ripe for replacement.

      Like

  2. Except when the client thinks it looks finished because you’ve polished the UI but there’s still lots to do on the back end. “What do you mean it’s going to take another 6-8 weeks? What you showed us looked finished. Why can’t we have it now?”

    Liked by 1 person

    1. I’m very wary of sugar-coated icebergs. If it’s ready to be user visible, it should be ready end-to-end. Finished means polished, usable, and working. Even if it’s 1/10th or 1/100th of the functionality you want.

      If the delete user functionality isn’t ready, just ship the profile page, and don’t show the delete link.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s