As software developers, we automatically know what our clients want. Even if during the requirements gathering phase the client tells you they want you to zig, you know that they actually want you to zag.

(Hopefully) obvious sarcasm aside, getting requirements and building software that the client wants is a common point of failure in our industry. I've worked with developers that were dilligent enough to read the business requirements, but ultimately disagreed with them and went ahead to built crap that no one ever wanted. David A. understands the importance of building things that users want, and was delighted when his prototype was well-received.

Of course, as a prototype, it was totally hacked together with crappy, insecure code, ready to be refactored in better shape. This was David's first foray into ASP / VBScript, and the prototype code made this pretty evident. Still, it was functional and gave the client something tangible to give feedback on.

The first change the client requested was a menu system to underpin the site. The task was delegated to Mr. Q., a senior developer on the staff. David apologetically handed over the prototype code, explaining that it was a prototype only and should be used to get the gist of how the system would operate, though little to none of the prototype code should be used in the final system. David elaborated on the menu system, offering suggestions for the final design and left Mr. Q. to work. In the following weeks, David kept busy fleshing out the rest of the system.

Finally, David's code was in good shape and he was ready to integrate Mr. Q.'s menu code. Mr. Q. handed over his code, so David did a quick code review to plan out his integration strategy. As it turned out, Mr. Q. used the prototype code except for a few changes:

  • In the prototype, menu items and links were database driven. They were now hard-coded.
  • In the prototype, a single stylesheet was used. In the new code, styles were defined inline on each page.
  • Every page was missing HTML tags, causing unpredictable behavior across different browsers.

The prototype wasn't pretty, but it worked. Mr. Q.'s code wasn't pretty, either. Plus it didn't work.

David confronted Mr. Q. about the code that was actually worse than the prototype and was stunned by his answer:

"I didn't know it was expected to work."

David realized that in all their discussions and all the documentation and requirements he'd provided to Mr. Q., he'd never explicitly said that he wanted working code.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!