Creating your program design

Question

what tools do you use to create your program design coding it?

Answer 1

Commit your ideas to pen and paper, sit down and embellish the idea a bit more, flesh it out a bit, then let the idea open itself a bit more. That is your starting point for documentation, then you can form a to-do list from that, and stick to it, if you have to change it, write it in. Of course, feel free to draw sketches, doodles to get your brain dumped onto paper.

You can use a blackboard or whiteboard.

Of course, entirely at your own responsibility, you can imbibe a few alocoholic drinks while mulling it over....but do not do coding while drunk or high as a kite, because, you will be reeling in shock afterwards when you see code and ask yourself - 'Did I really write that?'....or ... 'What happened to my computer?'....

Hope this helps, Best regards, Tom.

Answer 2

Depends on the complexity and scale of your project. For very small programs, I write some lines in pseudo-code and then code the programm down. If it has to do something with arrays, data structures, etc. I paint some sort of representation and try to think of the general and special cases. If several classes are involved, I start off with some UML diagrams (sequence-, class diagrams). Sometimes coding some sort of prototype and experimenting with it will do the trick. If someone has done the things you are trying to achieve before, read his code, try to understand it, build up on it, improve it.

Answer 3

I find a good way to plan how to code something is to think about it for a bit, jot down your ideas in short form, and then to try to code up some of your ideas that seem likely to work. Choose the simplest possible thing that might bring you closer to the first step of your goal and try to implement that and see what happens. Then after the first few hours / day coding, take a step back and see what you've learned.

And this is important: be prepared to throw away all the code you've written on the first day if necessary.

Treat it as a learning exercise. Now you know more about the problem domain, and where your first design performed well, and performed badly. Talk about what you've done with some colleagues, ask for advice. Show them what you've done and get them to critique it.

On the second day, delete everything you did wrong, and do it again but better. Repeat the process as many times as necessary, checking your code in each day to document your progress, your mistakes, and what you've learned. Keep talking to other people about what you're doing (assuming they have time). It's easy to blinker yourself into following a dead-end if you're working alone - so focused on your goal that you miss the big picture.

After the first week you should hopefully have made a lot of mistakes and learned a lot, so hopefully by now you have started to form a design in your mind of the best way to proceed.

An alternative way often suggested is to sit down for the first month designing and planning the rest of the project and documenting it all before writing the first line of code. The problem with this method is that at the beginning of the project you know least about what you need to do, how to get there, and what problems you might face on the way. I think it's important to choose a process that allows you to change your design as you learn more.

Answer 4

I usually sleep on it a night and try to visualize the general flow of execution. Once I've got that down, I figure out all the details as I'm coding. I find it very difficult to think at any level lower than general execution flow without actual code to refer to. Lastly, I refactor because usually what I end up with will have some design elements that are artifacts of how the project evolved and only make sense in that context.