| SitePoint Sponsor |
Hired a full time 40 hour dedicated php programmer. Im setting up guidlines and job descriptions.
What is a resonable amount of coding that can be produced in a 40 hour work week. Im talking about a project start to finish....planning ,database design, coding and debugging.
whats a resonsable expectation? How would you manage this?
Last edited by phantomceo; Jan 26, 2006 at 10:04.
...not sure, but don't underestimate the planning/design process: if this is done properly it can speed up the actual coding time tremendously.
any software out there to help with this project management?
This is a very hard question to answer. Given the complexity of the project, how much experience the programmer has with the project, there are so many variables that can be thrown into the mix that can affect how effective a programmer can be.
You can have two programmers with similar backgrounds who don't complete the same amount of milestones in the same amount of time. Some programmers spend more time on requirements analysis and testing while others go straight for the code.
Are you trying to hire a full-time programmer and you want to know how best to get your money's worth? The best way to gauge this might be to have the programmer write daily reports on what they accomplished so you can see how much they are able to get done. The thing with programming is, you can have good days and you can have bad days as a programmer. Some days you are just able to kick serious butt, and others you get stuck on a problem and you spend 5 hours on something but never accomplish anything tangible. They usually balance themselves out.
Sara
This is spot-on.Originally Posted by spinmaster
MS Project or www.dotproject.net can help
Sara
Thanks. Yes, I hired in inhouse programmer already and am looking to optimize the investment. I absolutly understand good days and bad along with good project planning.
I just want to have resonable expectations on both ends. So everyone is happy.
THANKS!!!!!!!!!!
I'm a full-time web developer, but I only spend about 3-5 hours coding on a good day. Why? Meetings, requirements gathering, support, email, etc etc. all take up parts of my day as well.
Be sure to factor that in while you're making your estimates. I don't think I'd ever factor in more than 30 hours of coding in a standard 40 hour week for a programmer, because I know it just won't happen.
In the beginning the programmer will have to get used to the setup, etc. Its a good time to feel each other out. Just use a lot of communication in the beginning and make sure you let them know that if they get stuck or have a question about something to let you know.
Sara
Depends...
There have been times I've went all week without anything; At times you just tend to take time out to further develop and refactor an idea you have, an algorithm that works, but you know that it could work better, cleaner, etc
In saying that though, that week isn't a waste, since at the end of the refactor, you have somthing which is more flexible, more re-usable, etc so it's time well invested - for me I tend to take time out a lot, one week for every 4 weeks for example, just to see if I can refactor something some more, so long term it's an advantage.
To generalise in such a question to me isn't fair to put a developer in that position, as it to a large extent, does depends on the complexity of the software in question; Also if I was to be honest, most of the work a developer does, doesn't actually produce 'x' amount of lines of script anyways, as there is just so many factors to consider, such as quality for example.
If you want 1000 lines of poorly developed script, over 10 lines of a much higher quality script, then I suppose it just about doesn't matter who your looking for at the end of the day, does it?
A script kiddie could knock out 1000 lines per day, or whatever you wanted
It's really true that all developers are different. I have anywhere from 10-20 developers working at any time, and they all have different levels of output. I have learned, the hard way, not to get frustrated when 1 developer is less productive than another. So long as they are reasonably productive, that's ok.
So, at any given time I might have 5 developers that crank out code like crazy, 5 that produce good amounts of code, and 5 that could be much faster but are still billable and reasonable.
Do I 'throw back' the slowest 5? No way! They are all valuable to me, even if they aren't the fastest.
The fewer our wants, the nearer we resemble the gods. — Socrates
SAGEWING LLC - QUALITY WEB AND MOBILE APPS. PREMIUM OUTSOURCING SERVICES.
Twitter | LinkedIn | Facebook | Google+
My 2 cents, as someone on the other side..
It really depends on the nature of the project, your management style, the coder's style, their experience, etc.
Personally, I like to spend a lot of time thinking about the project, considering all the possibilities of its use, talking to the client to get more details and learn their plans for it, thinking how it is likely to be modified in the future, etc. Then, I set up the database, mentally step through the various scenarios, and usually end up modifying it as I learn more details and think of new possibilities.
This process can take several days, and sometimes the client gets frustrated because they can't fathom how I can supposedly be working on the project, yet not have so much as a single "hello world" page online. Which I can understand, but it frustrates me, because they don't understand that I'm trying to save THEM time/money in the future by creating a versatile product that can smoothly accomodate future scenarios rather than having to be hacked to pieces every few months.
However, once I have everything set in place, it comes together far faster and better than it would if I just jumped in and blindly began spewing code left and right, and everyone's happy. So even if your coder appears to be slacking, stand back and give them the benefit of the doubt for a while until you learn their style.
One of the things that gets me hung up at work is when someone submits something without including all of the information I need, then when I request the additional info, it takes them weeks to get back to me with it, so the project sits around.
I often have 4-5 projects on the "back burner" because I'm waiting for additional info. Sometime this makes it seem like I'm taking forever to do things that I only spend a little actual coding time on.
amen! same thing happens to me quite often!One of the things that gets me hung up at work is when someone submits something without including all of the information I need, then when I request the additional info, it takes them weeks to get back to me with it, so the project sits around.
I often have 4-5 projects on the "back burner" because I'm waiting for additional info. Sometime this makes it seem like I'm taking forever to do things that I only spend a little actual coding time on.
Debugging can take anywhere from 5 - 20 of the 40 hours, really depends on how big the project is.
As long as progress is made, that's really all you can ask for somedays. I get stuck on bugs all the time that HAVE to be resolved, so debugging takes up more and more of my time. That, and I also end up debugging my co-workers programming too (she gives up too easily in my opinion....heh).
How motivated is the coder? I can code continously for days if I'm motivated enough.
Online Startups Insight for new entrepreneurs
And I'm sure the quality of your code takes a nosedive after hour 10 or so just like everybody else. Coding longer hours usually leads to bugs and mistakes that could have been easily corrected or prevented by taking a break for a while and coming back refreshed.
Not really. Coding relentlessly is not always hours of continous 'keyboard punching'. It's usually a lot of planning (done with coffee), keyboard punching (done with Led Zeppelin) and testing (done with pizza). And a cycle of these three being repeated. :-) Then ofcourse when I'm all done, I sleep for a week. :biggrin:
Online Startups Insight for new entrepreneurs
Yes, I will often spend a week planning with absolutely no tangible results, then it goes like wildfire.
I remember on one project in particular I spent a week planning, started coding, it was going really well, foolishly I left one of the most (if not the most) complicated things until the end, and as I was coding it, I realized that my "plan of attack" had a fundamental flaw, that I probably wouldn't have seen without experience, until I started coding. I had to restructure my db, rethink my strategy and make a few adjustments to code I had already written. This dropped my immediate and tangible productivity through the floor. It wasn't nearly as damaging or costly as having my work collapse during use, so in the long run, I believe it would actually save money.In many respects, programming is a service and works by the old slogan "you get what you pay for". Like almost anything where you put people in charge of something that will eventually affect your reputation, there is a great deal of faith and trust involved.If you want 1000 lines of poorly developed script, over 10 lines of a much higher quality script, then I suppose it just about doesn't matter who your looking for at the end of the day, does it?
A script kiddie could knock out 1000 lines per day, or whatever you wantedYou're just gonna have to trust your instincts I guess about whether they are taking for a ride or honestly trying to produce for you. Your instincts have gotten you this far.In the beginning the programmer will have to get used to the setup, etc. Its a good time to feel each other out. Just use a lot of communication in the beginning and make sure you let them know that if they get stuck or have a question about something to let you know.
That used to be my approach till I came across clients who changed their reuqirements on the fly.Yes, I will often spend a week planning with absolutely no tangible results, then it goes like wildfire.
Online Startups Insight for new entrepreneurs
and testing (done with simple test).and testing (done with pizza).
What do you mean by 'simple test' ?
The fewer our wants, the nearer we resemble the gods. — Socrates
SAGEWING LLC - QUALITY WEB AND MOBILE APPS. PREMIUM OUTSOURCING SERVICES.
Twitter | LinkedIn | Facebook | Google+
Its very difficult to quantify this type of question as there are allot of external factors that heavily influence time and quality. I have developed several projects some which have finish ahead of deadline and some way past it.
What I find is that often when planning a project in an unfamiliar field often the time is underestimated. This is always because of the obvious fact that you can't plan for things you can't foresee, for example if the requirements change within the development or as a result of the incompatible promises of third parties. Often clients can make promises that cannot be met when development starts which can add to time. An example recently was a client who promised to supply xml data feeds daily, started supplying csv!! This meant more development time etc.
Also I have found that you come across new things which influence time. An example would be security. An assumption when planning could be over ridden when development takes place and therefore more research is needed to secure the system or the vulnerability.
Therefore the bottom line is to be strict with the objectives but a bit less so with the time. This way you will get a stronger product which is likely to meet your demands and more. If you do the reverse, you will get the opposite.
It's a framework for unit testing PHP objects.
Simple Test is a Unit Test Suite by Lastcraft (Marcus, PHP Advanced Design forum), which you can download from www.lastcraft.com There is also a series of tutorials on the site, which would be a good introduction to unit testing, for you
Posting Permissions
Bookmarks