Joel Spolsky of Fog Creek software has posted an interesting article: http://www.joelonsoftware.com/items/2009/03/09.html
Reading it was one of those “ah! I knew that” moments – where you’ve experienced something, but haven’t really put it into words.
The gist of the article is that a programming project needs someone who doesn’t write code to ensure that the end users needs aren’t forgotten. And that is really important because the person responsible for coding the project will almost inevitably focus on solving code problems, sacrificing end-user needs. I know that I do that myself. If I’m in charge of delivering code, that’s the focus; if I’m in charge of the design, end user needs are at the forefront.
Even creating design mock-ups in Photoshop is best separated like that – if I do mock-ups for projects I’m going to code myself, it’s so easy to think about code implementation far too early and limit the design based on what’s easy to code. It’s better to write the functional spec and have another designer do the mock-ups because their goal will be the best possible UI, regardless of how cumbersome it might be to implement. It can’t be completely in la-la-land of course, mock-ups must be feasible. But as a rule, it’s better to start with best solution you can come up with and then simplify due to complexity and time constraints.
The only thing I can’t agree completely with is the need for coder and program manager to be equal in status, i.e., that one is not the boss of the other. I see the point that it leads to more open discussions, but it can also lead to lack of decisions. If the process comes to a stalemate, someone has to be able to make a decision and move forward. My experience is that a work environment that encourage and awards questions and discussions can get an open debate between boss and employee – but there might be differences in business culture between Norway and the US.