|
Seems like a better way to put it is: Design first, then develop. Which, in my experience, is a good idea whether you are responsible for the design or not. If you have no data structures or other programming limitations to work with, you can focus on perfecting the interface and then worry about making it happen. If you already have the program written, it is natural to want to take the easy way out and just slap up a form that matches the code. An aside, being someone who enjoys playing both roles, I find the design phase goes a long way to improving the structure of my application because I have time to get a better understanding of the requirements, program flow, etc. Every element I draw automatically turns into code in my head, thinking about how it is going to be implemented as best as possible. The program is already written long before I ever touch a text editor. Furthermore, programming is design. A programmer's job is to write code that is not only functional, but code that is visually appealing. Visual appeal is the factor that makes code maintainable or not. It is basic human nature to want to work on pretty code and reject ugly code. As such, it is wrong to say programmers do not have artistic talent. They exercise it each and every day. The only thing many programmers lack is practise in designing visual interfaces. Given all of that, I find it very unfortunate that we try to separate the design and development jobs. I understand the business appeal of trying to do the job twice as quickly with two people, but from a fundamental point of view, the separation only goes to hinder the quality of our software, in my opinion. |
To that end, I think it's a good thing that we recognize these are different roles. The fact that each role has a different set of audiences means they can specialize in catering to those audiences, which improves effectiveness. The issue is when we DON'T recognize the difference and try to lump them together.