Slashdot Mirror
Hiring Good Programmers Matters
Doctor O writes "Joel Spolsky (of joelonsoftware fame) has some good points and fun with numbers on the quality of programmers and whether it is more profitable to go with cheap or good programmers. His point is that a good programmer will simply create code of a quality that average programmers never can create. An interesting read."
I work in a large group of programmers of varying ages and backgrounds. I believe you can categorize programmers into 2 main groups.
The first, and the majority at our company, are school trained programmers. These are people whose main experience with coding has been either class related (where the emphasis is usually on theoretical applications) or employement related (where the emphasis is usually along the lines of "just get it done").
The second group of programmers, which I'm in, is the hobbyist turned professional. We are people that began programming for fun, and often program on weekends on side-projects. Data structures and interface definitions become part of our regular vocabulary, and it's often hard to talk to programmers in the first group regarding projects.
Also, from my own experiences at work, I can say that it's the smaller second group of programmers that end up carrying most of a software project, both in code output and internal design. Although the first group of programmers tend to do a better job at testing.
Another point to keep in mind that not all your programmers have to the above average, or even average. For example, we have a student helping out over summer. She just doesn't have the breadth of experience for us to trust her with architecture design or the most complex programming tasks, but there are lots of simpler, straight forward jobs that she can do. And working at around half my salary (per hour), she's a hell of a lot cheaper than hiring a graduate programmer with several years experience.
Actually, in some kinds of applications, poor programmers are actually on par or better than smarter programmers. Usually you do your best when you're writing code that is easy enough to understand, but hard enough to keep you interested. I, for one, have no patience for writing simple test UIs, for example, or webpages. But some other people find it challenging enough to keep them interested.
I'm sorry. The number you have reached is imaginary. Please rotate your phone 90 degrees and try again.
You pay one or several good developers to develop it in their extra time. They'll charge significantly less since you won't have insane deadlines. And you don't have to pay by the hour. You can say I want these features for this price, with a deadline of xx months out. Or, you pay people to work on various smaller parts of the whole as you have the money.
I don't respond to AC's.
If you want to add bodies, let them do review work.
Let them do process busy work as well.
A few months back we were too crunched on the schedule, but another project had cancelled so there were loads of bodies available. But putting them to work coding would have destroyed the project. As always, upper management didn't understand that. So when I was asked where I could best use some extra help, I answered truthfully: have someone else write all the freaking documentation and attend all the freaking meetings so I dont' have to. Tada! They listened and I ended up with four extra hours per day to get the work done.
p.s. Of course, management never learns. Another project is slipping and they're throwing people at it as fast as they can cancel projects. Sigh.
Don't blame me, I didn't vote for either of them!
Where you go wrong is that people don't actually know what they want!
I've written projects with HIGHLY detailed specs. I've talked to people high and low. I've gotten signatures in triplicate.
And, those are the projects that BOMB QUICKLY AND PAINFULLY.
The last time I tried that approach, I was told on the DAY OF ROLLOUT after 1.5 months of full-time development that it "wouldn't work" and had to be "totally redone".
I screamed, bitched, complained, waved contracts, specifications and all, before spending another 2.5 months rewriting the application. (while people were using it!)
So, now I do things differently. I spend a bit of time, get a spec, and send out an email to all involved, and wait for 24 hours. Then I write it, knowing full well that it will suck upon delivery, and I make this knowledge apparent, obvious, and common.
Then, the comments come. The text is hard to read. It doesn't include N-ARCANE-FEATURE. When you click the button called "Save", it saves it, but it's not obvious what you are saving.
Whatever. The feedback comes in spades.
So, focus on making updates quick and easy, and listen. That's the Linux way: release early, release often.
People will tell you what they like and don't like. Listen, and release an update when you add new features.
In my flagship product, I've released over 40 releases in a single year. It'd be painful, except that the product updates itself, and it takes me all of about 10 minutes to release. Really.
It costs each user about the same - 5-10 minutes, and they can do it whenever they like.
So, I release early, I release often, and I listen closely to the feedback. Users get what they want, and I get what I want. (Users' money!)
I have no problem with your religion until you decide it's reason to deprive others of the truth.
This makes me worried about government contracts. What happens when there isn't any 'market' and the software is essential to running a country?
In the UK that means that there is a bid. The lowest bidder gets it, they employ the cheapest coders on the planet, farm as much off shore as possible, and then waste millions supporting crappy software. We're now in a situation where we can't trust the government with ANY software creation. They got the passport software wrong (well to start with), they got the tax software wrong (New Tax Credits was a fiasco) and they got the air traffic control wrong (fortunately nobody has died... yet).
What Joel says rings so true that its scary to think that the really important software will NEVER be written like this. But what can you do to remedy the situation? Because there is no market, you can't expect competition to improve the quality of the code, the only incentive being fines to companies when they get it wrong - thats no incentive, that just makes accountants want to do just a good enough job not to get fined.
Do you open source the problem? While I agree that security through obscurity is not security at all, you will never get a country that thinks its a good idea to ahve its tax software open to all to see. There is also Brookes law to deal with and there is still no guarentee that you will attract the best of the best.
Anyways... fascinating article!
Scared of flying, pointy things snce 1979!