Some programmers are happy to do as asked, following the spec, and building useful code that does what it’s supposed to do, and no more.
Other programmers are happy to question the spec, to discover business functionality that may not have been known, and to engage more in design.
Sometimes, and ideally, these functions are separated; you have a programmer who solves problems made clear in the spec, and you have a software project manager/domain expert who designs the solution to be implemented by a programmer.
Having said that, it’s not unusual to find the two functions in a single person, particularly a developer with more experience within the problem domain (in fact, it’s hard to find a project manager who’s experienced enough to design a good solution, who isn’t an experienced programmer).
Standard project management technique would suggest you start with the scoping, and the environment (the “why” and the “what”), and only when you get to identifying the work, to get down to the “how”.
Frequently, the guys involved in organising the scope are not the guys doing the actual nitty-gritty work, so by the time they’re involved, the “why” and “what” should ideally have been specced out.
With software development, particularly with iterative methods, the “what” is usually figured out as part of each iteration, which lets the “why” leak in, and should ideally involve lots of two-way communication between the developers and the client.
This isn’t always how it works though. As I said above, it’s an ideal world that can separate the functions, and often a programmer with enough experience to connect business analysis with programming will already be filling that role in any given project.
Jeremy Smyth's blog 