Comment Re:Lots of bad information (Score 1) 110
All developers are not created equal. That is a given.
Your second point is penny wise and pound foolish. If that kid is writing something that you are going to use for a few weeks and then discard, then he should just hack stuff together as quick as possible. Otherwise your approach builds a house of cards. 'Slapping' together code is a bad idea. Sorry if that hurts your feelings, but it has been proven for years. Please read some books on code lifecycle and long terms costs of supporting code and cost of fixing crap 'slapped together' code over doing it right the first time.
So each of your points, based on your very limited specialized example, which fails to address true coding, which provides roi. Cause I'm not sure that little db interface that only you use is really a ROI item.
1. He may hold hands cause he needs help to do it right, or possibly to save time cause he's not real good at jdbc.
2. documenting - If it's only a small piece of db code that only you use, he can probably document it in about 1 hour. Be real nice if he gets hit by a bus, hmmm?
3. source code control - He can do it in 3 days, but 2 days into the project his PC hard drive explodes. You didn't have CVS/SVN/Something set up by default that all people use without though. You lose.
So, your limited example sucked. Your theory on ROI is proven wrong by more technical papers than I can shake a fist at. A more real example is you want that crappy db access stuff in 3 days. He gets it in 5 but it is reusable, well written, stored in sccs and has a nice 2 page document stored with it.
I fire you and give him your job. :)
Your second point is penny wise and pound foolish. If that kid is writing something that you are going to use for a few weeks and then discard, then he should just hack stuff together as quick as possible. Otherwise your approach builds a house of cards. 'Slapping' together code is a bad idea. Sorry if that hurts your feelings, but it has been proven for years. Please read some books on code lifecycle and long terms costs of supporting code and cost of fixing crap 'slapped together' code over doing it right the first time.
So each of your points, based on your very limited specialized example, which fails to address true coding, which provides roi. Cause I'm not sure that little db interface that only you use is really a ROI item.
1. He may hold hands cause he needs help to do it right, or possibly to save time cause he's not real good at jdbc.
2. documenting - If it's only a small piece of db code that only you use, he can probably document it in about 1 hour. Be real nice if he gets hit by a bus, hmmm?
3. source code control - He can do it in 3 days, but 2 days into the project his PC hard drive explodes. You didn't have CVS/SVN/Something set up by default that all people use without though. You lose.
So, your limited example sucked. Your theory on ROI is proven wrong by more technical papers than I can shake a fist at. A more real example is you want that crappy db access stuff in 3 days. He gets it in 5 but it is reusable, well written, stored in sccs and has a nice 2 page document stored with it.
I fire you and give him your job.
