One thing I haven't heard anybody discuss here, which is my favorite method of calculating development time, is to actually just start doing the work, and keeping track of the time you spend, before a contract, before anything. Then, after some period of time, look back on how much you've accomplished think about what's left to do, and you'll be able to offer a pretty good development time estimate.
Call me crazy, but this method works on lots of levels:
- Most of us are in this business because we have fun coding, so the time you spend (even if you don't get paid, or have to throw it all away because design decsions change) will have been fun.
- You learn tons each time you just start doing the work. I've written complete look-alikes of things like HTML::Template before I knew it existed. Of course it looks like the folks who wrote that did a much better job than I did. So what? Now know exactly what it needs to do, and I'm in a great position to evaluate it and to modifiy it.
- It's probably the method by which you'll get the best actual measurement of how long it's going to take. For smaller projects, you get it 100% right, and you bypass the "design specs" section all together. How many of you have had the experience that your clients only half know what they want, and part of what they are hiring you to do is tell them what they want? What better design spec is there than a working project? As long as you have good coding practices modifiying things to the final design (which is never the same as any "design specs" anyways) isn't that hard.
My direct response to you Siddartha is, unless your mortgage and kids are on the line and you won't like what it does to your life-style, then just jump in and do it. Damn the torpedoes. Definately do use CGI.pm, and probably use CGI::Application
these will both save you lots of time in the long run despite modest learning curve issues. Whether you use MySQL or PostGress or flat files, big deal, just use the perl DBI and switch later once you get things up and running.