Re: Starting a Large Project

[impossiblerobot]

For me, the most important step in any large project is putting together a good 'specifications' or 'requirements' document. If you can do this in enough detail, and have the client sign off on it, you can save yourself a lot of work.

The specifications will still almost certainly change, but at least you and the client can have some measure of agreement that the requirements have changed, and it gives you some ammunition when changes in scope make a project take longer or cost more.

Also, if you document every aspect of the design, including data structures, input/output, response time, etc., then writing the program is much easier, since all you're doing is translating the description into your language of choice (Perl, of course). Otherwise, you can end up writing a lot of code that doesn't do what the client thought it was going to do.

Update: I forgot to mention that if you're ever coding and you find yourself trying to decide which way the client would like the program to work, your requirements document is not detailed enough, and you should probably stop coding immediately and go finish it. :-)

Impossible Robot

[mattriff]

For me, the most important step in any large project is putting together a good 'specifications' or 'requirements' document. If you can do this in enough detail, and have the client sign off on it, you can save yourself a lot of work.

I'd like to second, third, and fourth that. :)

I've worked on several projects that skimped early on in the requirements gathering phase, and we suffered for it later. All I can say is, I'll never let that happen to me again.

Designing a beautiful architecture only to find that it can't be made to meet the end-user's needs is no fun. Making up the requirements as you go along is fun for a few months, but then it starts to get old.

As much as you can, it's good to know where you need to end up before you get started.

-Matt