When a product a colleague worked on recently shipped its first generally available release, the event was accompanied by a marketing fanfare of podcasts, press releases, and conference trips to beautiful cities with boxes of presentation materials, branded lapel pins, and flashing fridge magnets. My colleague gave a hugely successful presentation to customers and was rather taken aback afterwards when she was approached by a member of her company's marking team who asked why it looked as though the development team hadn't done that much to the product since the last presentation six months previously. She explained that the earlier presentation was riddled with hard-coded data, mocked-up screens, and, for the most part, was only done so that the developers and architects could show a test audience some ideas and concepts to garner reaction and feedback to help shape the finished product. In the intervening six months between the proof-of-concept demos and the final deliverable, a huge amount of work had taken place. Not just in actually coding the final code drop, but in making it conform to accessibility requirements; internationalization, performance and threading issues; security, tracing and error diagnostics; not to mention building a large suite of unit tests and a deep set of regression functional tests.

The problem with software is that most people's perception of an application is simply the user interface: the buttons, list boxes, and data that sit on the glass. To all but those who are themselves developers, there is little or no appreciation of the huge amount of grunt work required to make things actually work, some of which is often extremely tricky and requires sharp innovative developers, not to mention time and money.

This lack of appreciation for what goes into a finished product is something an old boss of mine used to call the "spreadsheet mentality." At the time we were tending to software contracts to create software that had to crunch large amounts of non-relational insurance data using batch programs. Our nemeses were the jocks who, having just managed to master an Excel pivot table with over 20 rows of data, had no appreciation of the scalability or network client/server issues and would heckle our meetings with cries of "Fools, I can do this all with my spreadsheet and database CD that came free inside my muesli box this morning."

This concept of people who don't appreciate software construction yet are able to participate in the decision-making process manifests itself in many dangerous forms at all levels of an organization - from the bean counter who lays off a development team with years of skill and experience in order to outsource the project to a far-flung colony to save a few dollars, to the manager who thinks that software quality is achieved by suffocating the development team with ridiculous processes and time-wasting status reports that do nothing more than fulfil the input requirement to fuel anachronistic and irrelevant reporting chains or absurd audit requirements.

Two powerful techniques that can be adopted to protect a project's expectations from its users are to use paper prototypes, thus avoiding any confusion whatsoever that anything remotely close to the finished product is being discussed, and to deliver small incremental pieces of functionality in an iterative agile manner to keep the heartbeat of the feedback loop between the user and development team healthy and current so the amount of code per deliverable becomes smaller and more finely finessed. In addition, the practice of chirping "ship it" to a developer who has shown a piece of clearly unfinished code should be banned in case anyone from marketing is in the room taking minutes. As with all things in life, we should be careful for what we wish for.