Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Parable of the Two Programmers (1985)

csd.uwo.ca

Post reply on HN
Print view View original

101–110 of 169 posts

Re: The Parable of the Two Programmers (1985)

#101

Post by VLM »

The meta message of the parable is programming is, in actual practice, an art, not a vocation or profession. For political / economic reasons we sometimes have to pretend its a vocation or profession, but it really isn't in actual application. Software architecture should be in the "fine arts" department at university, not a branch of finance, engineering, or math.

In art, people expect the highest quality producers to instantly produce effortless appearing product (music, dance, painting, sport, drama, whatever) and are generally willing to pay for quality unless they're a hopelessly tasteless neanderthal. The only time effort is rewarded in art is when parents watch their (own) kids perform.

One epic fail of the parable is it was written in an era of C (pascal?) dominance where 500 LOC means something different then from now. That would be at least 2000 lines of boilerplate-ish java (think of the classic "enterprise hello world" java implementation) or 10 lines of clojure and pretty much everything else fits in between. Something that has stayed constant over the decades, from my observation, is a "complicated functional block" takes maybe three hours long term total average, a "little bit less than before/after lunchhour", and the only determiner of how many LoC are produced in that time is language quality and programmer quality. Maybe another way to phrase it, is a correctly sized block on a project flowchart takes a couple hours in all languages for a given class of programmer ability.

Re: The Parable of the Two Programmers (1985)

#102

Post by chroma »

woah wrote: post #85
chroma wrote: post #53

Earlier quoted context omitted.

While emotions may run high, it's important to remember that this is an empirical dispute. It can be resolved simply by looking at everyone's git history. For myself, the least code I've written on any day in the past year is 20 lines. My average is around 100. The most is a tad over 1500. Of course everyone's different and LoC is a terrible measure and it depends on the language, task at hand, etc. But in general, m…

I'm curious to hear about how many problems you solve with these lines of code. I guess that's pretty much impossible to quantify though. Also, what languages do you work in? I'm not that experienced, but I had a notable experience working with a 5000+ loc app that was a nightmare to maintain and extend. The last guy had basically reinvented every wheel. He was even, in my opinion, reimplementing the DOM in places wi…

(Note: I don't mean for this comment to be perceived as bragging or showmanship. It's just that... well, you asked about my background.)

Computers have fascinated me since before I can remember. I spend most of my waking hours in front of them. I've been honing my craft for over 20 years. I've written and maintained projects in C, C++, C#, Java, JavaScript (both browser and server-side)[1], Perl, PHP (we all make mistakes), Python, Ruby, and a couple Lisps. In my travels, I've discovered and reported bugs in popular software such as Firefox, Chrome, Node.js, Apple's XNU kernel, and libxml2.

I completely agree that some programmers are like machine guns, firing off vast quantities of poorly-aimed code. I try my best to avoid that. I hate sloppy code. I hate repetitive code. Most of all, I hate re-inventing the wheel. If a decent library exists, I'll use it. I have no qualms with something Not Invented Here.

I pair sometimes. I do code reviews often. And I use as many profiling, testing, and static analysis tools as I can get my hands on.

It sounds like your ordeal made you a better coder. Those sorts of experiences are indispensable, but I've found it takes more to keep improving. It's very useful to become an expert on programming, not just an expert at programming. There's a growing body of literature to aid anyone interested. McConnell's Code Complete is still great. Michael Feathers has a book called Working Effectively with Legacy Code. It contains some great techniques for incrementally improving hard-to-maintain projects. Lastly, browsing It Will Never Work in Theory[2] is a good way to stumble into some academic papers that apply to your own work.

1. "JavaScript" is such a nebulous term these days, but I've worked on JS codebases using tools ranging from nothing (vanilla JS) to JQuery to Google Closure to React.

2. http://neverworkintheory.org/

Re: The Parable of the Two Programmers (1985)

#103

Post by gaius »

swatow wrote: post #33
jebediah wrote: post #4

Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is was to the point of 5 lines of code per day being exceptional.

No, this is just an extreme example of the "don't try to be a smart guy" ideology. In practice 100-500 LOC per day is normal.

Firstly, any real working programmer has days where they write no code. You are writing documentation, meeting with users and sponsors to discuss new features and schedules, doing code-reviews and mentoring, merging branches, debugging race conditions, meeting vendors, chasing dependencies in other parts of the company, a million other things. That brings the average LOC/day down.

I can't imagine anyone sustaining 100 LOC/day over the long term unless they think that cranking out HTML templates or something counts as programming.

Re: The Parable of the Two Programmers (1985)

#104

Post by tokenrove »

chroma wrote: post #53
elpachuco wrote: post #38

Earlier quoted context omitted.

100-500 LOC per day is normal. It is not. You are not writing a novel here. Yes, most of the time is spent thinking. Some days there is no coding because it is spent on just trying to figure out what to do.

While emotions may run high, it's important to remember that this is an empirical dispute. It can be resolved simply by looking at everyone's git history. For myself, the least code I've written on any day in the past year is 20 lines. My average is around 100. The most is a tad over 1500. Of course everyone's different and LoC is a terrible measure and it depends on the language, task at hand, etc. But in general, m…

These metrics such as featured in Mythical Man Month are usually based on the SLOC count at the end of the project, divided by the time, not how much code was committed each day. Your churn might be 100+ LOC per day, but hopefully that isn't all permanent additions to the codebase -- bug count seems to be proportional to LOC.

Re: The Parable of the Two Programmers (1985)

#105

Post by baha_man »

dankohn1 wrote: post #99
iamwithnail wrote: post #66

Earlier quoted context omitted.

This is the mechanic story all over: Guy takes his car to a garage because it keeps breaking down, and the mechanic leans in and listens to the engine for a minute. He goes and gets a hammer and listens to the engine again, and then raps sharply on the engine casing. The engine goes back into sync and stops breaking down. The mechanic says "that'll be £500, please." The guy's outraged: "But all you did was tap it!" M…

The origin of that story is Charles Steinmetz, and it involves Henry Ford, a $10,000 invoice and placing a X in chalk. http://www.smithsonianmag.com/history/charles-proteus-steinm...

According to Snopes[1]:

"Practically anyone famous for his knowledge can be offered up as the virtuoso in this tale... Nikola Tesla, Thomas Edison, George Washington, the electrical genius Charles Proteus Steinmetz... How long this story has been around is a mystery."

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

Re: The Parable of the Two Programmers (1985)

#106

Post by spiritplumber »

jakobegger wrote: post #82
greenyoda wrote: post #59

Earlier quoted context omitted.

"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 probl…

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 :)

Re: The Parable of the Two Programmers (1985)

#107

Post by rev_bird »

greenyoda wrote: post #51
Iv wrote: post #45

Earlier quoted context omitted.

> Conclusion: we don't want to pay related to the value we receive for a certain service, but to the amount of effort involved in the delivery of that service. 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 ne…

It's irrational because the 10 minutes of work that doesn't destroy the door is worth much more than the hour of work that does - replacing a door is expensive and costs the homeowner additional time and aggravation. Also, it's really more than 10 minutes of work, since the locksmith has to spend time driving to and from the customer. His fee needs to cover his travel time and expenses (gas, wear and tear on his truc…

I'm with you on the first point, but your second seems to undermine the first. The argument isn't "$70 per hour is reasonable, and a 10-minute call takes an hour." As far as I can tell, it's whether "Fixing the lock is not worth less because it took less time, the end result is what you pay for" is true.

Re: The Parable of the Two Programmers (1985)

#108

Post by hibikir »

jebediah wrote: post #4

Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is was to the point of 5 lines of code per day being exceptional.

In my experience, as an outrageously well paid programmer, I will touch a lot more than 5 lines a day whenever I am programming, especially if I include changes to the unit tests, integration tests and such. There are two caveats though:

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.

Re: The Parable of the Two Programmers (1985)

#109

Post by chrisbennet »

patrickmay wrote: post #91
jebediah wrote: post #4

Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is was to the point of 5 lines of code per day being exceptional.

When working on an existing system, I find it's a good sign if your SLOC/day count goes negative for a while.

That is wisdom...

Re: The Parable of the Two Programmers (1985)

#110

Post by GFischer »

alephnil wrote: post #86
hotBacteria wrote: post #84

The story ends well because the project was actually simpler than what it looked at first. Unfortunately, more than often, things happen to be a lot harder than expected What happens when, after 2 months of scribbling and playing space invaders, Charles realizes the project actually requires 3500 lines of code? He wants the project to succeed but now he doesn't have enough time, and he fears to ask for help because h…

If this story had happened in real life, and the problem had been more complicated than anticipated, and Charlie had realized this, it would be likely to fail, because he did not have enough leverage toward the upper management to get the resources required to succeed, so in that case the project would be likely to fail, or at least be severely delayed. However, Alan was making the problem more complicated by introdu…

Indeed, it's very important to match the structure to the problem.

I've seen real-world situations where the Charlie approach was clearly wrong - a maverick programmer that wrote a module on his own, only some light testing with end users, no peer-review, not even source control. The program was finished in record time (a month or so), looked good, apparently did what was required, users and management were delighted, he got a huge raise. "Charlie" went on holidays... and then disaster struck. He hadn't considered the impact on other systems, and a bug delayed the montly accouning closing process, costing thousands of man-hours correcting the errors. Other programmers had to go to his terminal to see the code... and found a huge hardcoded, unstructured mess.

OTOH, in the same company, they hired a Java Senior Architect "Alan" to lead a module, just a little more complex that what "Charlie" had done. "Alan" spent the first few months meeting with all possible stakeholders, writing process diagrams, selecting a 4-person team, then spent a few more months building a "perfect" software architecture, an entire ORM layer over the systems he had to connect to. Then they chose a complicated Javascript framework for the frontend which none had experience with. After a year and a half (over a year over budget), they finally launched a first version... which wasn't what users needed. A year and a half later (3 years total), they finally have a working system.

While he didn't get the credit "Charlie" got, everyone thinks "Alan" is some kind of guru and that he understands "hard" problems, and he's going to be given the lead (again) on an even larger project, which the company is betting several millions on.

Post reply on HN