|
in reply to Programming with Multiple Personalities
When you do have to play all three roles (UI-designer, tester,
coder), the best approach is to do the UI-design first (on paper),
then write your unit tests, then write the code. In this way, you
risk the least cross-contamination of design and testing with the
actual coding. Obviously you still have to be conscious of your role
(don't think about implementation while designing the UI, just focus
on the UI). And, of course, it doesn't all have to be up-front. You
can do the same thing in an iterative fashion so long as you make
sure you follow the design,test,code steps in that order for each
component.
|
Re: Re: Programming with Multiple Personalities
by Juerd (Abbot) on May 07, 2002 at 13:02 UTC
|
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.
| [reply] |
|
|
I usually find that if you design too much of the system architecture before designing a tangible user interface or "this is what the end user is doing with the system", I never manage to discover the entire set of issues or problems to solve.
This also has to do with communication. The users can't describe enough of what they want by themselves, and they can't give feedback until they have _something_ to commment on.
Thus, "what should I build?" starts with the user and the user interface (not nessecarily coding, but prototyping and desiging it). Then you can deduce what you need to build it, and how.
Once I know what to build, I find it helpful to implement small features, one at a time, all the way through. Start with a real easy feature to get going. Then do a real difficult one to try to encounter as many problematic design decisions as possible as soon as possible.
/J
| [reply] |
|
