|Problems? Is your data what you think it is?|
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.
In reply to Re: Re: Re: Programming with Multiple Personalities