As a Programmer, how much do you really need to know?

I was involved in an interesting debate today at work while discussing Code Complete. The discussion had turned to what we, as programmers, need to see in a spec. What do we _need_ to know?

On one hand, it was opined that we need to know the business logic and how the spec we're currently working on fit into The Big Picture. Some even went so far as to say that the programmer should develop the spec alongside the architect, so that they could ask questions and gain perspective on The Big Picture. This attitude presupposes that the specs will be flawed freqently. Additionally, it puts the developer in the position of having to second guess every spec they're handed. Keep in mind, we're talking about subtle flaws that only someone well versed in the domain would catch. Given, if the issues are that subtle, they could be difficult to detect, but proper design and testing should help. But, humans being what they are, if an architect knows that the devloper is double checking them, they are more likely to get sloppy, relying on developers to catch architectural mistakes. Domain knowledge could play an important role in early detection of such problems. This is pretty easy to do, if you're working on a single project or product. But, if you're in an environment were you may change teams, projects, or products regularly, it could be difficult to familiarize youself with a new problem domain every time.

The other side of this argument presupposes that the architect is doing their job. You still rely on good design and tests for finding and eliminating bugs. But, the programmer isn't as concerned with The Big Picture, as with making sure their piece follows good design principles and is thoroughly tested. The downside is you lose any early detection of flaws in the business logic. The upside is that responsibilities are clearly defined. If a bad spec gets implemented, the architect can not blame the devleoper. This speaks to part of what Code Complete calls "Intellectual Honesty": admitting your mistakes. The architect, knowing this, should be more consciencious of the design they are asking to be implemented, and will make it clear and specific. People new to a project won't be at a disadvantage because the designs , were made under the assuption of specific domain knowledge.

This is not meant to devalue "Intellectual Curiosity" about the project you are working on. It is only natual to wantto know more about your projects. The question is, is it necessary?