Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: Re: How to calculate development time?

by Siddartha (Curate)
on Jun 01, 2001 at 14:36 UTC ( #84894=note: print w/ replies, xml ) Need Help??


in reply to Re: How to calculate development time?
in thread How to calculate development time?

Thanks for the suggestion.

I am seriously looking into this. The only problem will be that I will need a dedicated host, or an ISP that gives me telnet access. The cost of the solution is also not that much, and the increase in productivity should more than make up for it.

Thanks again, I have received a lot of usefull information from everyone, but this is probably the most usefull reply to my specific needs.

-Siddartha


Comment on Re: Re: How to calculate development time?
Re: Re: Re: How to calculate development time?
by mattr (Curate) on Jun 01, 2001 at 17:11 UTC
    Hi, I wrote a pretty detailed response but Netscape crashed.. so here are the highlights.

    - Mysql is fine for this job, it will take longer for Oracle which is overkill. I've used both and Abigail's comments notwithstanding, I can tell you your choice is fine. I read most of the document she provided and while there are good points there are also a lot of people with great experiences on MySQL and I find much of it outdated FUD particularly with regard to the needs of your project.

    - You must have telnet access to stay sane now and in the future, you might need to look at the apache error logs or maybe compile your own perl modules some time. Rackspace is nice, I have not used them but have been very impressed with their responsiveness at night. ssh is better than telnet if you can get it. I recommend linux with RAID 5 disk array.

    - Unless you must do clickpath tracking or very high volume accesses, don't use mod_perl on this project. It is a lot of fun but you need to be able to restart the server and it takes a lot longer. There is not a ton of documentation compared to the number of issues that come up with it, so experience is important.

    - Don't do credit cards in the beginning. It is complicated and other companies and laws will be involved.

    - As for project schedule, you may have trouble on this project if you allow the client to eat up your development time with figuring things out. Development time starts after the spec is signed.

    - You need to get a dialogue going and confirm your understanding of what they are saying. The client has to participate in developing a detailed specification, and must also be coopted to promote success of the project by the following activities:

    - Signoff on screen mockups and detailed functional descriptions before development

    - Signoff on delivery of parts, if you can handle that.

    - You make weekly risk assessment reports ( a number 1-10 may be good) and use "that increases risk" and "decreases risk" when new functionality or deadlines are mentioned. The idea is that you do not want to get behind the eight ball trying to defend yourself against an unrealistic deadline from feature creep or some other problem that may crop up.

    - Check out some of the ideas of XP programming philosophy, it has old and new ideas and may give you some ammunition if you use some of them.

    - It will probably take 2-3 times as long as you think. Keep a schedule with expected man-days per task, including testing on your side, bugfixes, testing on their side, content delivery, whatever. Actually content delivery is in addition to that. The variables you generally have include the number of people on the project, the budget, the time until delivery, the quality/robustness of the code, and the SCOPE. Scope means how much you are going to do. It is easiest usually to change scope so you must get the client involved so they do not make it difficult to change scope.

    - There was a very good recommendation above that you look at how your man-days projections match reality and then multiply the difference as a time stretching factor across the entire project. I didn't believe it when I first heard this but it is true.

    - Make different phases of the project. The first phase is consulting which you should get paid for, it involves making the spec and figuring out what they want down to screen mockups (line and text is fine). Also a designer is probably going to be involved. Make sure of what you are responsible for, including do you write HTML. Supported browser types may be another thing to make sure of up front.

    - The different phases will make it possible to move functionality to a later phase if you need to. Have the client set priorities (no, they can't say 100% or nothing) so that you can identify what core functionality must be perfect by launch, what is best effort, and what is later phase. Then you can get them to put feature creep functions into the next phase, or get them to change other variables like schedule or maybe remove a different function.

    - Get feedback as soon as possible from other people in organization so you don't get nailed at the end. Also try to decide as much of the software architecture as early as you can, preferably well before signoff on the spec.

    It looks like this is a dangerous project if you don't think of some of the above things. You will have to help your client figure out what he/she wants, and you are only working part time while there is a learning curve for some of the things you will be doing. I would say give yourself a large buffer, start the clock after signoff on the detailed spec, and get the client involved in the process so they can see what will happen if they become unrealistic about things. Don't handicap yourself in the beginning by agreeing to a lump payment at the end (especially if you are meeting milestones and have a consulting report deliverables in the beginning), and if schedule is really important then discuss the possibility of budget changes to add another guy if you really need to at some point.

    That's all for now, good luck!

Re: Choice of ISP
by Anonymous Monk on Jun 02, 2001 at 16:40 UTC
    Have you looked at Positive Internet? Full ssh access, mysql, mod_perl, the works. You can add your own modules, but normally you're better off asking the very helpful tech support guys to add the module to the server so everyone can use it.

    From experience on a cgi/database heavy site (http://www.moonfruit.com), mod_perl is *essential* if you are anticipating scaling to larger numbers or users. "use strict" and you'll have no problems with mod_perl.

    MySQL has limitations, but is cheap. No transactions (OK - no "normal" transactions...), no stored procedures, no sub-selects (ie no "SELECT * FROM users WHERE user.id IN (SELECT userid FROM admin_users)". But it *is* free, and it *is* included in many web hosting packages

    You won't get a decent site done in your spare time in four weeks. There are issues you haven't thought about yet. For example, have you thought of including an admin interface for the people running the site to delete/edit users, get stats, change passwords etc? Of backing up the data and being able to recover it?

    Clients, eh? Who'd have 'em...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://84894]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2014-12-27 01:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls