Weird - I tend to do it exactly the other way around. First, I write a backend interface and document it, then I write tests (although I often skip this part) and when I'm done, I write a user interface (if any).
If you are going to use Windows, you know there is an API that you can use. How would you feel if you had to wait for someone to code stuff after creating a nice GUI? I see a GUI as a front-end to code - it's not the actual code. Code should be modular: if someone wants to write a different GUI, that should be easy and doable with the same backend interface. The user interface must not have much code: important things should not be part of the user interface.
I don't write a front-end for an application of which I don't know how it is going to work, and I refuse to write unit tests before doing the actual coding. If you don't write your code first, you're restricting yourself too much.
1. Code 2. Tests 3. User Interface, and then refine the code to help the interface, write tests as bug reports come in, and adjust the user interface as much as you want.
As for playing different roles yourself: it's the only way to have good communication :)
- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.