- "Lines of code" is a meaningless metric. Please stop using it.

- Charles obviously did something when he appeared to be doing nothing. What? Unfortunately, we're never told.

- There is no treatment of the things that likely are important: analysis, design, prototyping, feedback, fine tuning, etc. Did either programmer try any of these?

- The story infers that using modern magical brilliance is better than using tried and true methods, without ever mentioning what either one is.

I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned.

I can agree that LOC is a terribly abused metric, but it is not completely without meaning. It's just really rough and better left untouched in decisions involving money.

I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned.

I think it's just an invitation to reflect on the ways that this story comes true. People mistake needless, unhelpful processes for "tried and true methods" and software "architects" frequently over-engineer and create solutions worse than the problems.

I'm not under any illusions that you (and most people here) don't already understand this. It probably wasn't aimed at you. There are many programmers today who don't understand that this kind of story plays itself out every day to some degree. The fact that the opposite story can also happen doesn't detract from the point that is being made.

Now, if we make the reasonable assumption that my rewrite was not a candidate for the IOCCC or Perl Golf, I think it's pretty clear that lines of code is not meaningless. A >75% code reduction while maintaining the same functionality under reasonable development conditions is almost always going to make it easier to test, debug, and maintain the system/module. (This assumption isn't unsubstantiated either. In a code review, I was even complimented on the quality of my documentation.)

You hear about these kinds of vast disparities among software developers all the time, but I still find myself shaking my head that I actually saw it in real life. Now I'll freely admit that "lines of code" is mostly meaningless the way it is usually used. But don't throw the baby out with the bath water.

So you can't measure less LOC means it's better, it really depends on the quality of the code from a maintainability standpoint not just the size of code.

The guy who did the code review found the 1950 very readable, and much simpler.

There are no absolutes. But that doesn't make these metrics useless.

And rereading this essay again shows at least part of the motivation for making arc a smaller language than lisp.

As a long-time programmer, it was pretty clear to me what Charles was doing when others around him thought he was doing nothing: analysis, design.

And sometimes if you get a problem solved right, it doesn't need tuning, and if the solution is a small number of lines of code, your prototype might be just what you ship. Many large entrenched shops cannot imagine that this can possibly be true, so the bureaucracy resists or eliminates any such solutions.

To me what is troubling about this story is that it represents what happens in software organizations--both sides.

For instance, I recently corrected a bug in my code that had been there for a long time. The final code is dead simple. But it took years to detect the bug, and weeks of hard work and analysis to figure out that simple solution. (And of course, who knows -- maybe it's not as hard as I thought, and if I were just brilliant enough I would have instantly seen the solution. If I have no clue what the truth of the matter is, how is my (hypothetical) one step removed boss supposed to make sense of it?)

First, they are anecdotal. Second, why are the programmers not taking control of management positions if they know so much better?

I sure would like to get to play computer games at work, design software from scratch, always end up with clear and short code, make software with usability that users love, and be showered with money.

But realistically, I think Alan created the best product for the company. He analysed what was needed, to avoid the risk of creating the wrong software. He got several programmers into the project so the bus-number was higher. He set up facilities for reporting bugs. He started testing early.

Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. Once the software has been written he could leave the maintenance to the others and move on to something more interesting than maintaining accounting software.

There is no inherent evil in anecdotes. This is obviously fiction and was not intended to be used as evidence. If it were, then you would have a reasonable complaint. The purpose of a little story like this is (from Wikipedia): "to reveal a truth more general than the brief tale itself, or to delineate a character trait or the workings of an institution in such a light that it strikes in a flash of insight to their very essence."

Second, why are the programmers not taking control of management positions if they know so much better?

I see this asked a lot and I don't understand why. First of all, the traits (not skills, but traits) or interests needed for taking control of management positions are different (vastly different depending on the company) than the traits/interests needed to be a good developer. Second, don't forget that our fictional hero Charles eventually quit the company and presumably found a better place. Finding a place that fits you more is sometimes better than trying to change yourself to fit the management mold in a particular company.

I think Alan created the best product for the company.

Did you read the same story I did, or are you rewriting it into your own parable?

Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's.

That would be good I think. Let's also imagine how good Alan could be if he could learn to see past the inflated corporate policies, procedures, and checklists and focus on the crux of the problem.

It may be that the Charles, on average, produce better solutions with less resources than the Alans, but that individually, more of the Charles projects fail catastrophically.

Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's.

Let's also imagine how good Alan could be if he could learn to see past the inflated corporate policies, procedures, and checklists and focus on the crux of the problem.

Both excellent, I think. But further, let's imagine an organization that arbitrates the risk of each Charles by simultaniously working many cheap, risky Charles on the same problem and managing the results with an Alan-like process.

If the Charles are software startups and the Alan-like process is "the Internet," this could work.

And you write "second, why are the programmers not taking control of management positions if they know so much better?" That question is outside the scope of the fictional dataset of the original post, but see "Jack and the Beancounter" in http://www.skotos.net/articles/BTH_27.shtml for a related fictional study.

And you write "but realistically, I think Alan created the best product for the company." Perhaps I am just being trolled. But at least this was a good excuse to refer to Jack and the Beancounter!

In other words, in this case the reader identified with Alan because that best describes how that reader works and acts, and they are just instinctively defending their position, even though, clearly, the parable portrays Charles as the better of the two. (Of course, that could be my bias, as I identify with Charles).

Someday Charles will encounter a challenge that does require a complex project with sophisticated processes and support. Maybe he will fail -- after all, he hasn't proved his ability to manage such a project. However, suppose you have a project that requires four programmers, a well-documented analysis phase, and infrastructure for ongoing support. Would you really rather assign Alan to the project?

Alan did prove that he could manage a complex project. However, he also proved that he designs software that is much more complex than it needs to be. If he needed four programmers and a bunch of infrastructure to handle what should have been a one-man job, how big a team will he need to handle what should require four programmers? Sixteen is an optimistic answer. The project is likely to fail.

Plus, considering that Alan's solution created unnecessary ongoing costs in terms of training and support, how many projects can you afford to let Alan implement? Even this simple project resulted in ongoing costs in training and maintenance. Imagine if you expected Charles's solution and got Alan's instead. Blammo, there goes your budget. I hope you know where you can make some cuts so you can afford to maintain Alan's software. You talk about Charles leaving the maintenance of his code to other people. What are you talking about? His five hundred lines of simple, well-designed code needs no maintenance and can be enhanced later by any competent programmer.

There are many projects my company has done in the last several years that were simply done right and never touched again. They hide in plain sight, flawless but basically forgotten. That's the kind of code Charles produces. There are also lots of projects that we touch over and over again. That's Alan's code. Those projects have snappy names that everybody knows -- we need good names, because we refer to those projects constantly. Every little change in operating conditions exposes new bugs and requires more tinkering. They're like sores that won't heal. Everyone regrets that when we had the time and money to do those projects right -- like Charles would have -- we instead produced a never-quite-right time suck -- like Alan did. The quality and cost of maintenance of a company's software depends entirely on how much Alan code it has. The more Alan code, the more bugs and the higher the cost. A company can only support so much Alan code on a given budget. A company can support a nearly unlimited amount of Charles code.

Finally, you are unwise to assume that Charles needs to "learn to cooperate and participate in a group like Alan's." Maybe he already knows how. Should he have used more resources and incurred more overhead than he needed just to prove he knows how to manage them? That's the kind of bureaucratic head-count-whoring waste that companies are constantly trying to fight. Frugality should be encouraged, not punished.

Also, the bus number is usually only applied to programmers whereas product managers, executives, etc all dont' have the same bus number over their head. It is almost like companies hate the fact they have a valuable technologist or programmer and try to consistently offset that.

Now of course if the single programmer is not communicating or after the project is done they play complexity games then that is different (only one person can read their code) but usually I see the 1-2 man teams obliterate the 3-7 person teams on a regular basis.

Programming is not construction, the number of programmers on a project has little to do with success ever. So the bus-number is quite silly. What about the bus-number for the CEO, or the project manager, or the one person that handles billing etc.

http://en.wikipedia.org/wiki/Anecdote

No proof required.

However, I think that anecdotes offer much more than just a way to avoid having to prove your point. They're not merely for gaining power over weak minds. They can be useful among intelligent, analytical folks as well. They can serve as a supplement to real data. They can illustrate a point of view more accurately. They can communicate a feeling or a sentiment, and can pack more meaning and generate more tangents of discussion than dry statements of fact. A startup begins with something like an anecdote, an idea that may be crazy, but stems indirectly from a myriad of past experiences.

Our brains are not binary storage units, and therefore anecdotes and parables have historically been used to help people remember things. Similarly, you cannot bring to the table a hard set of data for every life lesson that you've learned, and therefore you have many beneficial things to teach others that you cannot directly prove. If you're a good teacher, you'll tell an anecdote to help people remember (nonfictional preferred of course).

Yes, an anecdote is a tool. It's great for remembering things, poor for proving things. It just so happens the only conceivable purpose of the original story was proving something. Now, if he had anecdote which helped you remember, say, the standard form of the quadratic equation or something else people just needed to remember, then it would be using the tool for its proper purpose.

Absolutely wrong. The purpose of the original story was to provide an illustration.

Now, if he had anecdote which helped you remember, say, the standard form of the quadratic equation...

There are ideas and lessons worth remembering that aren't mathematical facts.

This is just another example of "bullshit baffles brains" and that it takes competence to recognize competence.

For instance, were the 'enterprise' team to be headed by a capable technical lead that forces his team to produce reasonably readable, reasonably documented, reasonably maintainable and futureproof code, then the situation would already be very different. If we add to that that the inexperienced hacker prodigy would produce working code much faster, but his code would turn out to be brittle when someone else has to take care of it, because he does not yet have experience in interacting with lesser gods via his code, then the match would be even more equal. We may still prefer the hacker, but we would be forced to think about the trade offs involved.

There are only so many things that you can force upon a team of programmers, and overall quality and cohesiveness aren't among them.

"Enterprise teams" are not, inherently, profoundly stupid in their practice of software engineering, and not all "hackers" inherently produce worthwhile, quality code.

This completely fabricated fable of software engineering is a simple straw man argument, and I've flagged it accordingly.

That convincing management regardless of your productive output is what matters at the end of the day? Perhaps at some organizations, but it's not a particularly accurate, nuanced world view.

I doubt this story would be conveyed in reverse -- the stereotypical "rockstar hacker" produces vast reams of code that will fail catastrophically, but comes out ahead by, upon 'completion', immediately pushing responsibility for the disastrously buggy code to the "stodgy" enterprise engineers who get called in to maintain the project. The "rockstar" moves on to the next project, where he'll repeat this performance, and the stodgy developers get poor performance reviews.

On the other hand, it does seem to be a nice passive-aggressive way to complain about getting demoralised by a manager who couldn't understand the hacker mindset.

EDIT: Couldn't beat curiosity, it's from March 20, 1985 according to http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...

http://www.pbm.com/~lindahl/mel.html

Let's change the story a little and see if the response is any different...

"Back at Consolidated, Charles spent some time thinking about the problem. His fellow employees noticed that Charles often sat with his feet on the desk, drinking coffee. He was occasionally seen at his computer terminal, but his office mate could tell from the lack of typing (and his always-interesting commentary at lunch) that he was likely reading Hacker News."

Seriously though work isn't track and field you don't win by being better than who ever came in second. You win by working to the best of your ability.

It's all about perceptions. If you're a crap coder, but suck up to your boss, wear a smart suit (or whatever the conventional clothing is at your place of work), always arrive at work on time, etc, then you'll do better than if you're a brilliant coder, but wear unconventional clothes, come in on work late, etc.

For people who just cannot make the jump and understand what the author was saying, re-read the article, and instead of Charles playing Space Invaders, have him reading Hacker News instead. I think you'll see it takes on a whole new meaning for you.