|
in reply to Coming up with code design
I do a combination of things that are mentioned, however most of my applications are striving to be the front end for small online databases (either data entry or retrival.) I start the applications by talking to the future end users to make sure that what 'I understand' as the end desired functionality is what 'they understand' it to be. Once I know that the expectations are the same, then I go back to my cave to invent and discuss with my staff.
We usually start by drawing up a series of data structures. So, I look at the programming through the eyes of a DBA first, (ie: What tables and data fields are necessary to do the job.) We have three very large white boards in our development area, and about 5 small ones that are not mounted to the wall. They turn out to be great idea generating tools during our discussion and planning stages.
Once we're satisfied that we have the data structure intact, draw up a final version on one big white board. Then we start by drawing up the form, (ie: What is the user going to use? How is it going to affect our data structure?) We usually talk out as many possibilities of entering data, etc, until we're comfortable that we have the functionality desired. We may modify our data structure if we see something that we've overlooked along the way. When we're satisfied that we've covered all of the bases, we draw up one final set of form(s) on another white board.
The last part is that I break the project up. I start people documenting what we're going to work on, doing a layout design that is efficient, breaking everything out into small tasks, making assignments, deadlines, etc. From there I have my 'map' and we move forward.
- Mission
"Heck I don't know how to do it either, but do you think that's going to stop me?!!"
|
