How do you prepare your projects?

[eluser]Mahmoud M. Abdel-Fattah[/eluser]
I just tried DIA and it's good , you :
http://www.gnome.org/projects/dia/

yes, it's gnome, but its available for windows too.

[eluser]phused[/eluser]
I'm a project manager and a coder myself, when working I use Scrum a lot, that's a form of "agile" development.

http://en.wikipedia.org/wiki/Scrum_(development)
http://www.amazon.co.uk/Agile-Software-D...770&sr=8-1

[eluser]The Wizard[/eluser]
I recommend reading the book pragmatic programmer, which has goooOOood tips how to be a better programmer, work with PEN AND PAPER, write things down BEFORE you try to code them.
Did i mention the PEN AND PAPER? ( NOT KEYBOARD )
DRAW! Draw your database scheme and after everything is planned,
code.

[eluser]Ñuño Martínez[/eluser]
[quote author="Fero" date="1237128546"]"let's code and determine functions while coding"[/quote] This method is a simplified version of "Extreme Programming". I use it on my current job because I never have all the information about the project. That's not my fault. My boss never, never, never explains me everything I need, he always hides something. Once I've finished something he says "Oh, nice work! Now, add this new little feature that seems simple but actually it will ruin everything you've already done". I think it's the worst way but I can't do anything else. u_u"

On my personal projects I write a simple document with specifications and objectives. Then I draw some simple UML and flowcharts then I star to code. I do it in small steps and everytime I finish one of these steps I revisit all the documentation and I modify it if I think I can do it better. It's not perfect but it is a much better way. ^_^

My optimal development environment is a desktop, pens and paper. Really. herrkaleun is right: Pen and paper are the best friends of a software developer.

About code edition I use gVim for everything (PHP, Objective Pascal, C, ...), and I use "make" to compile and SVN too.

[eluser]jedd[/eluser]
[quote author="Fero" date="1237165674"]jedd, it's not about database, but flowchart of application itself - classes, controllers, functions within each controller - same with methods and views ...blalblalbla..[/quote]

Hi Fero - not sure what you mean by 'same with methods and views' here. What problem are you having with designing methods? Are these different to the functions? I thought they were the same.

[eluser]Mahmoud M. Abdel-Fattah[/eluser]
[quote author="Ñuño Martínez" date="1237396712"]
About code edition I use gVim for everything (PHP, Objective Pascal, C, ...), and I use "make" to compile and SVN too.[/quote]
Man, I've a question, why using such a basic editor although u can save 50% time by using any IDE !

[eluser]Ñuño Martínez[/eluser]
[quote author="Mahmoud M. Abdel-Fattah" date="1237403300"]Man, I've a question, why using such a basic editor although u can save 50% time by using any IDE ![/quote]

I don't see how I can save 50% time by using an IDE. Vim has code completion, fast search with and/or without regular expressions, muli-file edition, syntax highlighting for almost any programming language, can use "make" to build programs, can use "gdb" to debug programs, it's scriptable, has built-in POSIX man browser...

I don't see it's so basic editor (or do you mean it's a BASIC editor? ). May be you're talking about the old Vi (without the "g" and the "m").

[eluser]jedd[/eluser]
I'm with Ñuño on this one - if Quanta (the IDE I use on KDE on Debian) would let me use a vim kpart for the editor window I'd be happy as a pig in poop. Nothing is as fast as vim for moving around inside a text file, or making changes to it. (Okay, emacs maybe, but I don't know it, so can't compare.)

People that have only ever used toolbar / mouse-driven editors will never really appreciate the performance gain you get by never having to move your index fingers more than 1cm from the f and j keys.

[eluser]Mahmoud M. Abdel-Fattah[/eluser]
[quote author="Ñuño Martínez" date="1237407274"][quote author="Mahmoud M. Abdel-Fattah" date="1237403300"]Man, I've a question, why using such a basic editor although u can save 50% time by using any IDE ![/quote]

I don't see how I can save 50% time by using an IDE. Vim has code completion, fast search with and/or without regular expressions, muli-file edition, syntax highlighting for almost any programming language, can use "make" to build programs, can use "gdb" to debug programs, it's scriptable, has built-in POSIX man browser...

I don't see it's so basic editor (or do you mean it's a BASIC editor? ). May be you're talking about the old Vi (without the "g" and the "m").[/quote]

Sorry Ñuño, when I searched for it , I found this one :
http://portablegvim.sourceforge.net/ and from the screen shots, I guessed that it's basic one.

[eluser]Daniel Moore[/eluser]
[quote author="Ñuño Martínez" date="1237396712"]This method is a simplified version of "Extreme Programming". I use it on my current job because I never have all the information about the project. That's not my fault. My boss never, never, never explains me everything I need, he always hides something. Once I've finished something he says "Oh, nice work! Now, add this new little feature that seems simple but actually it will ruin everything you've already done". I think it's the worst way but I can't do anything else. u_u"[/quote]

I hate that. That's why I quit my "job" and went freelance. Now, if a client tells me that, I can say, "Sounds great, but it's not in the contract we signed. I'll get back to you with a quote for the additional work involved in that."

I generally try to come up with a good flowchart ahead of time that I can present to the client, showing a representation of the functionality of the site. That way, if there are any misunderstandings, they are generally cleared up then. Also, when the client sees it laid out like that, they generally start coming up with their changes before you start to code, which is much easier on me, as it is easier to modify a flow chart than to change the guts of the coding. It's just good business sense.

I generally don't come up with a quote for a job until I have charted it, because it also helps me to avoid the pitfall of "I forgot I would have to do that there..." so I don't spend a lot of extra time coding something I left out to start with that I won't be compensated for. Also, once charted, it's easier to run it by the client as part of the signed contract of the function of the application.