> follow more easily the spirit of the spec instead of just the word. It also allows you to use your experience and expertise to tell the writer of the spec th

> follow more easily the spirit of the spec instead of just the word. It also allows you to use your experience and expertise to tell the writer of the spec that they have written a pile of junk and that what they are asking for is not what they need. Sometimes when I have done that I have also discovered that it was not what they wanted either but simply what they thought was practicable. Together we were able to thrash out a better spec that achieved the ends that were necessary. I wish that people would remember that the vast majority of people writing code are doing it inside the same company or even department that will be using the final program. It is often the case that at least some of the software developers in such teams have as much or more expertise in the domain as the customers commissioning the software; it would be a dereliction of duty to fail to question a specification that seemed pointless, inconsistent, or inadequate to the problem it was purported to solve.