The Parable of the Two Programmers (1985) • Hacker News Board

Re: The Parable of the Two Programmers (1985)

#61

Post by jakobegger » Sun, Jan 25, 2015, 9:37 AM UTC

I don't believe some parts in the story.

1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data.

2) A coder that spends a few weeks all by himself to implement a spec and then delivers a perfect product seems implausible even for an experienced coder. Specs are usually ambiguous and often don't even describe the problem that actually needs to be solved. It takes a lot of talking to clients to discover what you actually need to do. Halfway through the project you'll realise that half of the spec should be changed. If you just implement the spec without talking to anybody, you'll end up with code that solves the wrong problem.

But then there are things I can absolutely relate to. Good solutions seem simple and obvious in retrospect. But it takes a lot of effort to come up with simple solutions.

Re: The Parable of the Two Programmers (1985)

#62

Post by barrkel » Sun, Jan 25, 2015, 9:43 AM UTC

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.

Green-field software should be well in excess of 5 lines a day. If the software is old to the point that nobody fully understands it any more, and previous maintainers have left the company, the number of production lines of code added per day may easily be lower than 5.

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.

Re: The Parable of the Two Programmers (1985)

#63

Post by lmm » Sun, Jan 25, 2015, 9:45 AM UTC

thaumaturgy wrote: post #23

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…

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

Re: The Parable of the Two Programmers (1985)

#64

Post by SixSigma » Sun, Jan 25, 2015, 9:47 AM UTC

anaolykarpov wrote: post #35

There was a MOOC on Coursera called "Irrational Behaviour" and one of the stories there is about a locksmith who in the beginning of his career used to fix a door lock in more than an hour, with lots of effort and almost always destroying the door. His clients were happy to pay him the 70 dollars he charged for the operation and also tipped him most of the time. As time went by and his experience increased he got to…

The Parable of the Handyman's invoice

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

Re: The Parable of the Two Programmers (1985)

#65

Post by [deleted] » Sun, Jan 25, 2015, 9:50 AM UTC

jakobegger wrote: post #61

I don't believe some parts in the story. 1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data. 2) A coder that spends a few weeks all by himself to implement a spec and then delivers a perfect product seems implausible even for an experie…

[deleted]

Re: The Parable of the Two Programmers (1985)

#66

Post by iamwithnail » Sun, Jan 25, 2015, 9:52 AM UTC

anaolykarpov wrote: post #35

There was a MOOC on Coursera called "Irrational Behaviour" and one of the stories there is about a locksmith who in the beginning of his career used to fix a door lock in more than an hour, with lots of effort and almost always destroying the door. His clients were happy to pay him the 70 dollars he charged for the operation and also tipped him most of the time. As time went by and his experience increased he got to…

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

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

Edit: Crap, beaten to it.

Re: The Parable of the Two Programmers (1985)

#67

Post by ai_ja_nai » Sun, Jan 25, 2015, 9:54 AM UTC

This parable is somewhat untrue, as it pats over the "good students engineers" shoulders, while throwing "cowboy programmers" out in the cold.

Unless you are producing libraries or frameworks, management don't care about internals of software. It's an engineers' problem next time they ask for a modification. Management care about having their problems solved. That's why relations between management and engineers are so notoriously dysfunctional: engineers want to produce art, while management wants to sell stuff to customers.

A manager inspecting a code? Really? A manager congratulating with engineers for releasing a half-working software while going off budget? Seriously? Managers hate engineers as much an normal people hate lawyers: they make everything sound way too complicated to squeeze more comfort zone to roam into.

Lone cowboy programmers that can conjure working stuff in a minimum time are praised by management, and insulted by colleagues.

And, since this parable was probably written by a disgruntled, good scholar engineer, I think this whole story is a little biased...

Re: The Parable of the Two Programmers (1985)

#68

Post by ai_ja_nai » Sun, Jan 25, 2015, 10:00 AM UTC

thaumaturgy wrote: post #23

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…

I met a lot of cases; in some of them I was on the slow team side and in others I was the lone cowboy.

The problem is not if it happens, the problem is that our industry still sucks a lot.

Re: The Parable of the Two Programmers (1985)

#69

Post by Terr_ » Sun, Jan 25, 2015, 10:04 AM UTC

neilk wrote: post #40

thaumaturgy wrote: post #23

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…

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, ba…

I think he meant "Cowboy vs. Normal", as opposed to, erm, "Normal vs. NIV-addled incompetence".

Re: The Parable of the Two Programmers (1985)

#70

Post by jarcane » Sun, Jan 25, 2015, 10:13 AM UTC

webreac wrote: post #39

That is why I love perl: the manager can not understand it and can not say it was simple.

I wonder how much language popularity is affected by this effect.

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