Look, there's no moral to this story and very little to glean from it because it's about a situation that's ridiculous on its face. It's written to appeal to cowboy programmers to make them feel better about their prejudices in software development.
Can any of you actually relate a real-world case where a 4-month-long team-driven effort produced some code to solve a problem that could be solved by one cowboy in 3 months and 20% as many lines?
This was the 90s, and the client was a big corporate programming consulting company. They wrote software for big corporations or the government. They couldn't get a website done internally.
The spec meeting was memorable, because they'd say "We want a form on the website that sends emails," and I'd say "Okay," and then they would look at each other, baffled. I realized later they expected pushback on every single item in the spec. We were just agreeing to everything without even thinking about it – their demands seemed modest to us.
So, we whipped up something that worked reasonably well with good old HTML and Perl, and even had some CMS-like features. It didn't take more than a few weeks.
I later met that internal team that was continuing to work on their ill-fated website project.
They were too elite to use something like Perl. They were working on a web server. From scratch. In C. They proudly showed me how their web server could serve a web page. They had even worked out how they could show a preformatted table of numbers, by printing it inside a textarea.
I've had the experience of refactoring my predecessor's code and ending up with 20% of the number of lines. Inexperienced programmers tend to write repetitive code instead of looking for abstractions to simplify the problem.
I worked on a project where half or so of the code was copy-pasted from somewhere else in the same codebase.
The original author claimed that this way is better as it allowed him to see what the code does without jumping around the whole codebase.
When dumped and replaced by one of the better OSS versions in a few days by a developer who got fed up, things "magically" got much better, very quickly.
No praise or career boost at all for the developer in question, though. I think a large number of people (from management down) were embarrassed by the whole affair and wanted to forget about it. It seems that praise can only be dished out if you didn't embarrass somebody important.
Their system had many thousands of classes, mine probably had less than 50. Theirs used pretty much every technology in J2EE (this was a few years back) - mine used a very small set. I didn't even have to work very hard....
Let's have a thought experiment this way: imagine picking 4 programmers and ask them to implement Git from scratch, can you imagine any scenario in which they would take at least twice longer than Linus to produce the first working version? I certainly can.
Yes, I have real-world experience of that kind of ratio. All it took was some unreasonable non-functional requirements, many coming from a "chief technical architect" who had the authority to overrule everyone and made a bunch of poor decisions.
The scenario's quite believable. Many "programmers" out there got transferred from a user department, lied on their CV, and/or cheated the aptitude test. They can't code very well. Or maybe their coding level's up to scratch but they can't coordinate and communicate with other programmers, hence meetings and numerous drafts of what's been agreed on. Or perhaps work is hard to find or some programmers are getting older, so they deliberately complicate the task or the program to keep themselves in a job.
> Can any of you actually relate a real-world
I know about 5 cases. I have been on both sides of this story. Plus there are similar cases outside of programming.
Lets just call it luck, shall we?
The problem is not if it happens, the problem is that our industry still sucks a lot.
Our industry is filled with people who are "cowboy programmers" and think of themselves as Charlie when in reality they're more like Alan, and are attributing what is actually pure luck and circumstance to their own brilliance. There's an especially high concentration of this BS on HN. You only need review the HN threads about the HealthCare.gov website to see this in action.
That's not to say this sort of scenario doesn't exist, never occurs, etc. It's just that there is likely to be an extraordinarily high number of people who read HN who believe they have experienced it (on either side), even if an objective evaluation of the circumstances would reveal they haven't.
> Charles announces he has completed the project. He submits a 500 line program.
> Charles did produce about 5 lines of code per day. This is perhaps a little above average.
Obviously that's not the point though.
A single developer outperforming a team is not that far-fetched - under ideal circumstances. It is obvious that there is a lot of overhead from communicating and coordination in team development, and the biggest drop in efficiency is scaling from a single developer to a small team. If a project is just small enough that a single developer can handle it, it is clearly the most efficient. The problem is that the lone-developer approach is totally non-scalable. If it turns out halfway through the project that it will require 20% more work than originally estimated, then the lone developer will have to add two or three colleges at a late stage - and since there is no written spec, the project is probably going to end up being even later and bad quality code. But of course this is not considered in a parable written to show that the lone coder-approach is superior.
Also the 5 factor difference in lines of code and bug count for solving the same problem is not far fetched either. But I think it has nothing to do with the number of developers but rather on culture and competency. It might just as well be the lone developer who writes a lot of bad code to solve a simple problem. Of course it could be a very competent single developer compared to a team of mediocre programmers, but it could just as well be the other way around. And in a team development effort, the most competent developer may perform code reviews and so on, so the overall code quality is better than just the average competency of the developers on the team.
The major difference in the two approaches in the parable is that the one team actually produces a written problem analysis and spec, while the cowboy has it all in his head. The story suggest that the lone developer actually produces a perfect problem analysis and is therefore able the write the perfect program without the overhead of producing written spec. However, the boss/customer have no way of knowing until the program is finished. If there was an error or miscommunication in developing the problem analysis, it is too late to change now, or at least will be much more costly than if it was discovered in the specification stage. Also, in the real world it requires communication with the customer to develop and verify the spec. It the story the development happens completely without outside input, which almost never happens in the real word. Even if developers would wish it was the case.