• Coding
  • Your Project's Life Cycle

Just want to know what stages you guys take while working on a project whether its Windows or Web based application. Do you usually plan your project, model it and then implement it, or just start working on the programming bit straight away.

When iam working on a small tool for my personal use, i usually start programming it straight away, but this might work with small apps, but when it comes to medium or large projects i usually find myself planning everything on papers and drawing some flowcharts or brainstorms. I think this way is very effective because when you get to the programming part it will be easier as you have everythin ready and you know what are you trying to accomplish.

I just wanted to know how you plan your projects and post somethin in the programming forum to keep it fresh :).

Regards
first i do a PoC (proof of concept) that is a quick hack to verify the feasibility and usage of the solution.
after this, i brainstorm the pros/cons choose the appropriate technology, define the boundaries & limits of what needs to be covered, cross out thoughts/features that are not of essense for first release and then redo the job.
btw, that applies to my hacks on OS and when i script. im not a programmer, can you believe that?
well it depends on the size of the application and the type of your client
sometimes you can just quickly map it in your head, write basic documentation and finish the thing, re-document again and re-adjust to new reqs

I also take into consideration the client type, sometimes the client can be such a pain, so you have to be very clear and careful about writing requirement, send it officially via email, wait for confirmation blablabla ... divide your work into v1 , v2 , v3 , make sure you get paid for v1 first, then extra features go to v2 , otherwise in some cases, you starve to death before client is done with "talabet"

What I like to do is get the requirement and discuss them with the client
then i would proceed to building a first draft Design and make a demo
I would then show the client the demo , I even leave it with him, cuz once the client "sees" the software, he usually starts remembering stuff and it becomes more real to him, so in the screens he starts telling you things, and like this they have something to discuss at the client company... you can show the demo to different ppl, make sure nothing is missing.... like this you minimize the cost and pain of changing stuff in ur design

usually parallel to the demo, i do the POC of the core of the application, test and re-test.
then i install the core at the client and tell this is beta , to see if any real life scenarios cause trouble
in parallel i develop/update the other features, i would let the client do lot of testing instead of me :P and like this, with the client giving you live feedback on the application you tend to work faster, send bug fixes and log in remotely to do updates
( that is of course for doing private dev. or custom made stuff , for teams and software houses it is a totally different approach... but i tend to prefer Agile Developement :) )

but usually i never work on the programming straight, unless it is very small 1 hour work or something like this
that applies to my hacks on OS
Do you create mod version of an OS.

Mir, I agree, some clients can be more helpful than others, they just give you their needs straight away without laf wdwaran.

I've done several commercial small tools, before i started i collected all the information from the client, and then sent back what i collected to the client, just to make sure everythin is right, so nothin goes wrong while in the development and testing phase.

As for the testing part i often send a demo of the project and/or a screen video of the program. Then if thats what the client wants, i do some final touches and then send it. But this doesn't finish here, you always get a feedback that the program is missing something, or something isn't working.
Road map, starting out with the requirements.
Yah I guess flowcharts are good for anything then super small scriptlets...
It keeps you from constantly reorganizing your app and hitting dead ends.
But i dont use them... I write app like an artist would draw on a canvas...:rolleyes:
12 days later
Since I code mostly in java and python, I find UML to be a perfect choice for big projects. It comes in REALLY handy when working with a team.
if the program that im working is bigger than the usual POC, i just do a quick draft of what the gui should be if any, and maybe a few bullets here and there and i start to code
7 months later
i dont plan (except the DB structure, but it grows while working too)

i just start coding
and after a while i curse myself and say i will plan next time, which i for sure dont do :D
al_jamal wrotei dont plan (except the DB structure, but it grows while working too)

i just start coding
and after a while i curse myself and say i will plan next time, which i for sure dont do :D
That's a common problem. If you don't want to plan at least follow a design pattern to make your life simpler later on when your project tend to change. MVC is a common web pattern.
8 days later
For small apps I usually run directly into the IDE and start coding after I have seen that all the different components are feasible and developed the solution and objective in my head, I also do some research before starting. As for big projects, I usually start by brainstorming everything on paper, I write some parts of the code that need analysis on paper and I do a UML diagram. After the analysis I start programming on the PC. :)