Oh god, this thing's actually getting traction here.
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?
Yes, I did just that. Actually I would guess it was more like 2%.
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.
"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?"
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.
But sometimes you can see the possible abstractions only after the fact... I often end up deleting a lot of my own code that turned out to be unnecessary.
Then there's the situation in industrial control systems where sometimes you really itch to do that, but you can't because the return statements mess up the tight timing :)
Can't you use stuff like gcc's __attribute__((always_inline)), or just straight-up C macros, for cases like those? Worst comes to worst, you can always use m4/cpp/some other preprocessor, although that does tend to hurt...
Yes. I worked at a company that spent hundreds of thousands of dollars, and nearly a year, on a server monitoring system that never acheived a high enough timeseries resolution to actually solve the problem it was funded for. Then a 20-year veteran of the company stepped in and wrote a 50-line shell script, pushed it to the relevant machines, plugged it into the timeseries database, and solved the problem. He called it his 89¢ solution.
Eww. Were there extenuating factors though? The monitoring system was somebody's pet project, or was purchased under contract on the hopes and dreams of sales, or the monitoring software did work but not in that specific environment, or...?
I've seen this exact same thing too. The "extenuating" (if you could call it that) factor was that the monitoring software was written in house and it was just shit. It might have been a pet project initially, but it didn't end up that way. It was just continued out of some combination of habit, risk aversion and not invented here syndrome.
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.
IMHO, the person selected to run the original project was a beneficiary of the Peter Principle, and on top of that, left the company before the project was completed. I wasn't directly involved, but I specifically remember the hero of the story complaining about having been "sold a bill of goods" -- i.e., the company was promised the new system would perform screamingly, but when push came to shove, it didn't.
Absolutely, I finished (as in actually got the system to meet requirements) a system in 6 weeks that a team of ~15 (all gone by the time I had got there) had failed to do in a year.
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....
Yes, I can relate, and I just barely started my career in software development.
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've seen situations like this. As a rule of thumb, problems that fit into the head of one person are more efficiently solved by one person on its own than by a team.
This, 1000 times, this. If you ever find yourself having difficulty cleanly separating a task, than you are going to spend more time defining the separation and integrating the parts than have having a single person do the task.
> 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?
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.
> [Alan] asked his department manager to assign another three programmers as a programming team
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.
You're going to get a lot of "yes" responses to your questions that themselves are going to be embellishments (or outright lies), omit context, pretend that refactoring an existing set of code is the same as writing it from scratch under the same conditions, etc.
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.
Yeah, the parable is wishful thinking by a developer who wants to be left alone and code without having to communicate with anybody. There are rational reasons that this is not a viable approach for most non-hobby software development.
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.
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?