in reply to Re: Programming with Multiple Personalities
in thread Programming with Multiple Personalities

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.

  • Comment on Re: Re: Programming with Multiple Personalities

Replies are listed 'Best First'.
Re: Re: Re: Programming with Multiple Personalities
by jplindstrom (Monsignor) on May 08, 2002 at 23:24 UTC
    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.