1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data.
2) A coder that spends a few weeks all by himself to implement a spec and then delivers a perfect product seems implausible even for an experienced coder. Specs are usually ambiguous and often don't even describe the problem that actually needs to be solved. It takes a lot of talking to clients to discover what you actually need to do. Halfway through the project you'll realise that half of the spec should be changed. If you just implement the spec without talking to anybody, you'll end up with code that solves the wrong problem.
But then there are things I can absolutely relate to. Good solutions seem simple and obvious in retrospect. But it takes a lot of effort to come up with simple solutions.
It's explicitly labeled a parable: "a simple story used to illustrate a lesson." It's not meant to be literally true. The second programmer's inexperience is just another reason why his boss judges his work to obviously have been easy.
Yeah, but it's interesting - the parable would definitely work better if Charlie were the super-experienced engineer who knows enough to value simplicity and Alan were the fresh-out-of-school greenhorn still impressed by fancy one-size-fits-all methodologies.
The point of this parable is that neither company has any clue what the actual value of the work done was. Alan looked like he was working hard and was rewarded for looking like he was working hard. Charles looked like he was goofing off and was rewarded for that.
Yet when you compare the results, Alan took 24 programmer-months to solve the problem, and Charles took 3 to do it better. If the companies had some way to objectively value the work done, Charles is clearly vastly better. But they don't.
It's got nothing to do with the specific techniques involved. It doesn't even weigh in on the reason for the difference -- is Charles brilliant compared to Alan's normal, or did Alan just stumble and turn a simple task hard? That's all irrelevant.
The point is just to illuminate how hard it is to know the value of a developer's work. I know I've run into that repeatedly in my career.
If you just implement the spec without talking to anybody, you'll end up with code that solves the wrong problem.
Good, then they'll pay you again to write it a second time. As the Demotivator definition of consulting puts it: "if you can't be part of the solution, there's lots of money to be made prolonging the problem."
1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data.
2) A coder that spends a few weeks all by himself to implement a spec and then delivers a perfect product seems implausible even for an experienced coder. Specs are usually ambiguous and often don't even describe the problem that actually needs to be solved. It takes a lot of talking to clients to discover what you actually need to do. Halfway through the project you'll realise that half of the spec should be changed. If you just implement the spec without talking to anybody, you'll end up with code that solves the wrong problem.
But then there are things I can absolutely relate to. Good solutions seem simple and obvious in retrospect. But it takes a lot of effort to come up with simple solutions.