The Parable of the Two Programmers (1985)

I don't think that's a fair conclusion. There's much more going on here.

Locks are security for people. If I call a locksmith and he takes over an hour to open or fix my lock, I think, "Oh, good, even a professional is going to take some time to get through this. It's pretty secure!" If the locksmith is done in 10 minutes, I think, "Holy shit! With the right tools and know-how, someone can completely bypass my security in ten minutes!" This isn't so shocking around here, because most people on HN know just how vulnerable most security systems can be. Many people will not have that knowledge and be comforted by a locksmith taking longer.

Also, when you hire a locksmith, you usually watch the locksmith do his work- either because you're locked out of something and have to stand around uselessly, or the guy is in your house and it shouldn't take too long. This makes you invested in his effort- if it takes an hour, you watched the locksmith work for an hour. It's hard not to pay, given that you saw how long it took, and how he was working at it.

The same standard doesn't seem to apply elsewhere- if my steak takes an hour rather than twenty minutes, I'm not going to pay more for it, I'm going to complain to the manager. If the oil change takes too long, I'm not going to be happy about that, either. If I buy a cabinet, I usually don't care if the carpenter took 10 hours or 20, I'm going to want to pay based on the quality of the cabinet.

I think your conclusion is true in some situations, but it's definitely not universal to all work.

The mechanic says "that'll be £500, please." The guy's outraged: "But all you did was tap it!"

Mechanic replies "it was a pound for the tap, and £499 for knowing where to tap."

Edit: Crap, beaten to it.

In the first case, the repairman came, fixed the thing in 20 minutes, seemed competent, and I gladly payed him.

In the second case, the company sent an inexperienced employee, who couldn't figure out the problem, and spent 2 hours trying everything before finally deciding the most expensive component needed to be replaced. I was very unsatisfied, especially since they charged me for all the seemingly pointless troubleshooting time.

So maybe it's not only important to make a lot of effort, but to also appear competent while working?

http://www.90percentofeverything.com/2010/12/16/adding-delay...

I also wrote about it. It's real. Many customers are not happy if you make it seem too easy.

After spending a number of minutes fiddling with some impressive-looking lock picks and exercising what must be years of learned skill, he couldn't unlock the door. Sheepishly, he put away the specific tools and pulled out a dummy key + a rubber mallet.

The locksmith put the dummy key into the lock tumbler, whacked it once on the head with the rubber mallet, and the door unlocked. From the time he produced the tools to the time I was inside the house was well under sixty seconds.

I thought, Why didn't he just do that in the first place? And concluded much the same as you've said -- $70 for thirty seconds of work might seem steep and some people need the song and dance. Personally, I was grateful to have on-demand service like that available so quickly :)

http://www.snopes.com/business/genius/where.asp

But is that irrational? This seems to be a personal preference. By refusing to pay the same price for 10 minutes of work or one hour of work, we assert that we do believe in a certain income equality. "Disturbing someone for one hour vs 10 minutes" is not a necessarily irrational way to look at the situation.

Locks are actually a very good (pathologically good?) example of this, because we usually have no idea how well and how often they succeeded and a single failure can be catastrophic. Therefore, it's very hard to tell how good of a job the locksmith who installed or fixed it did without being a locksmith yourself. Compare cars: With a car, you drive it around pretty often, and you get a feel for how it handles and smells and sounds relative to the baseline established when you first got it. There's a constant evaluation of factors relevant to how the car is actually doing. With a lock, if the lock is put in well and functioning properly, the successful evaluations are mostly unnoticed unless you have a camera watching the lock 24/7.

While I agree that Charles is the exception, I don't believe meritocracy is a valid solution; I'll always bet on Charles:

If the project was actually a "3500 lines of code" problem, then Charles might have taken longer to think about it, but it's my experience that Alan never would have finished.

However, Alan was making the problem more complicated by introducing a lot of accidental complexity, and I have often seen that this is done even when the problem is more complicated than anticipated. Such a project could easily create enough work for 10-15 people in the hypothetical scenario in the article if the project had enough necessary complexity to be a four person project.

It is very hard to distinguish between what is necessary and accidental complexity, and that is precisely the point of the article. Prestige is very often bound to how many subordinates you have rather than how well you solve a particular task, so making your project artificially complex can be a strategy for climbing toward upper management. This may of cause be a conscious or unconscious from the employee/manager in question.

The trick is to ignore the detail of the spec, and understand what they actually want better than they do.

If you get that right, then the actual coding becomes insignificant, and everyone is happy

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."

Cool story, but I have trouble believing parts of it.

It is indeed the case that the characters are vastly different in terms of skill, and that is sort of the point. Alan did spend time developing his skills, but it was focused on frameworks and processes, and not effective programming or problem solving. Maybe he just didn't have the right start, didn't know what he didn't know, and just went the wrong way from there. But management, and Alan himself, can't tell the difference.

I think that's the ultimate take-away. Non-programmers and "bad" programmers can't recognize good programming, even if they look at results. Well they can, but it takes a lot of time and luck to come across comparable situations. It seems like an intractable problem. They don't know who to trust; and there doesn't seem to be a way to find out for them, except to be genuinely good at developing software... but how to know which way to go about that?

We Lisp/FP fans crow about how easy and quick dev in more expressive languages is, but to a clueless manager that's potentially exactly the problem. If it doesn't look like work, then the manager is apt to wonder what they're paying you for.

Whereas JavaEE ...

It's a shame it never actually stated the specification of the program. It seems like that would be the kind of thing you would need to know to form a fair opinion.

I'm not sure how obvious the underlying point is -> programming languages and methodologies are structured by political requirements.

Programmer A is writing software. He knows nothing about perception management and status plays.

Programmer B is furthering his career and angling for a raise. By accepting 'corporate coding standards' he has proven he knows how to play the game and uses the project to increase his status.

The quality of the finished product, in terms of user experience and practical usefulness, isn't nearly as important as the social processes that created it.

IMO the interesting question is how much this applies to coding culture and language and OS design as a whole.

You know, people keep saying that, but I'm yet to find one example of it on real life. Yes, there are contexts with many rules, but I never found one that you couldn't modularize into person-sized problems.

That said, for several times I've solved in a month or two (took six once) problems that other people struggled with for years in the "corporate way" of development without any kind of success.

Older code has a lot more functionality, so every line of code is capable of leveraging more. 5 lines of code in a mature system may do more than 500 lines in a new system. But a bigger factor is figuring out which 5 lines to write. A third of the time can easily be spent researching the code trying to figure out a plan of attack, and the remainder iteratively debugging different variations of 5 lines validating (or invalidating) assumptions made about the code's emergent design during the planning phase.

And I'm not counting test code. Test code is usually cheap to write, if the code is testable. Writing lots of tests is an easy way to inflate lines written, should you be stuck somewhere in the dark ages where they actually measure productivity by such a discredited yardstick.

Don't read anything into the 5 lines of code per day. This is a pretty old article and even then, that would only be a reasonable figure if you take a large number of people on a large project and compute an average for everyone. In other words, counting refactoring, fixing bugs, re-writing things, doing administrative work, and so on towards the time elapsed. And even then it would vary so much from one project to the next that you couldn't get a reasonable representative number, though 5 LOC per day would certainly be possible.

First, you will not be coding every day. There's requirements gathering, setting up environments, build systems and such. Depending on what you are working on, this could be over 50% of your time.

And second, and perhaps more importantly, most of the lines you touch will replace lines that you, or someone else, has written in the past, instead of just adding more functionality without touching the existing codebase. For instance, 5 months ago I started working on a project that had been written by two junior programmers that did not understand the language they were using, functional programming, or the problem they were solving. The code was full of repetition, bugs, and there was no way to make heads or tails of what it was actually solving. So I started refactoring, working on eliminating duplication, and trying to build abstractions. After a week, I had made a good dozen commits every day, but they were on top of each other: total LOC actually went down. Only after that week of coding that didn't add to the codebase I could see the places where refactoring just wouldn't do anymore, and was able to figure out what to rewrite, and how to add the additional requirements.

So I had spent a month on a 15K LOC codebase, and ended up with 12K LOC that did more, had more tests, ran faster, and made sense to the people that would end up owning the product in the long term. But yes, I mucked with over 100 lines of code most days.

Situations like that happen to experienced programmers all the time.

we're talking about quality lines of code: debugged, qa'd, and working as expected. perhaps even after the customer has had a chance to peruse the beta. you will be surprised how much time you'll spend in meetings and how hard navigating and contributing to large projects becomes.

curiously, the number of lines of quality code expected by a developer has not changed much since "the mythical man month" was written, which was about IBM machines in the 60s, despite the obvious advances in programming languages and programming environments. it's still around 10 or so.

If it's a meaty problem that is not well understood, or a language or framework I'm unfamiliar with, or I sense the situation is complex enough that an early bad decision could lead to unforeseen troubles later (and I should tread carefully), very few or no lines are written during the day.

On the other hand, if it is similar to a thing I have done many times before, and I'm comfortable with the problem, the language and framework then there is much less time thinking and StackOverflowing and I can go at nearly typing speed. (Likewise, if the code is quick "one of" type things for tests or throwaway stuff). More than several hundred lines of code a day (JS or Python) in cases like these is very achievable.

This doesn't count things like html templates, css etc (although sometime that take a bit of thought as well).

[edit] And you will also write a lot of code you throw away; sometimes you need to solve 90% of the problem the wrong way to discover the right way.

If you consider abstract mathematics, it is easily seen that many mathematicians find most of their inspiration in the aesthetics of their ideas. Somehow the way we teach maths obscures this fact from the students.

Oh, and if you didn't already: Read «Zen and The Art of Motorcycle Maintenance». Aside from being a great story, it goes into detail about how technical work becomes art when done with Quality in mind.

Likewise if anything Charles made it blatant that he was not 'working', he was playing games and scribbling on paper with legs up on the table. Doesn't seem like feinting hard work.

Are you a programmer?

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.

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.

Who/what's there to stop you doing just that, once you have taken "the opportunity to take the money and run"?