
The Parable of the Two Programmers (1985) - ims
http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html?
======
anaolykarpov
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 a point where he was fixing the door
locks in 10 or 15 minutes with virtually no disturbances for the customers.
His tips started to fade off and his customers became outraged at his 70$
charged for those 10 mins of work.

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.

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

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.

~~~
c54
I think this is mostly true.

However, if you were watching someone prepare _the_ most exquisite steak, and
it took lets say a full hour to trim the meat, get the pan ready and properly
buttered, cook off the edges of the steak, etc, and you were sitting there
watching the chef go through this metiMaybe we just care about seeing the
complexity in an operation for it to have value.culous process, then perhaps
you wouldn't be upset that it took so long--and most likely would enjoy the
steak more, having seen the entire complxex and careful process to cook the
thing.

Similarly, if an oil change was a complex operation and you watched the
mechanic half-dismantle your car to change whatever needed changing.

Or if you watched a programmer bounce around the screen in vim for 20 hours;
coding, testing, tweaking, and debugging.

------
hotBacteria
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 he knows he is labeled as a lazy and arrogant guy.

So he works long hours to fix the situation, then he burns out.

Source? This is somehow happened to me. Several times.

This story can be true, people like Charles and simple projects exist, but
these are exceptions, not the rule. It's easy for a beginner to believe he is
that guy and then experience a death march [1] Things can go wrong for Alan,
but he has a team to support him and his managers know he is working at
something complicated.

I'd like to be Charles one day, but for now I'm Alan.

[1]
[https://en.wikipedia.org/wiki/Death_march_(project_managemen...](https://en.wikipedia.org/wiki/Death_march_\(project_management\))

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

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

Not to mention, the company will be paying Alan and his team much more than
they’re paying Charles.

It’s my suspicion that people will give more weight to people they’re paying
more, simply because they’re perceived as more valuable - independent of any
other hard data. So despite having already spent more money on Alan, they’d be
likely to continue doing so, due to the perception of hard work and the
perceived value to the company.

~~~
ctchocula
I read an study testing an idea similar to yours, but with wine. They
organized a study in the guise of a wine tasting event where there were 3
bottles of wine, but 2 bottles were marked up (one from $5 -> $50 and another
from $10 -> $90). Even though people didn't know they were tasting the same
wine, they said the the more expensive one tasted better. The other half of
the study was with the prices removed, people couldn't guess the more
expensive wine. The conclusion from the study was that "Individuals who are
unaware of the price do not derive more enjoyment from more expensive wine."

Source: [http://www.wired.com/2011/04/should-we-buy-expensive-
wine/](http://www.wired.com/2011/04/should-we-buy-expensive-wine/)

------
wting
Related Hacker News comment:
[https://news.ycombinator.com/item?id=8941621](https://news.ycombinator.com/item?id=8941621)

From 'Software Requirements & Specifications' [0], by Michael Jackson (not
that Michael Jackson, and not the other one either), published in 1995, a
parable [1]:

'What do you think?' he asked. He was asking me to tell him my impressions of
his operation and his staff. 'Pretty good,' I said. 'You've got some good
people there.' Program design courses are hard work; I was very tired; and
staff evaluation consultancy is charged extra. Anyway, I knew he really wanted
to tell me his own thoughts.

'What did you think of Fred?' he asked. 'We all think Fred is brilliant.'
'He's very clever,' I said. 'He's not very enthusiastic about methods, but he
knows a lot about programming.' 'Yes,' said the DP Manager. He swiveled round
in his chair to face a huge flowchart stuck to the wall: about five large
sheets of line printer paper, maybe two hundred symbols, hundreds of
connecting lines. 'Fred did that. It's the build-up of gross pay for our
weekly payroll. No one else except Fred understands it.' His voice dropped to
a reverent hush. 'Fred tells me that he's not sure he understands it himself.'

'Terrific,' I mumbled respectfully. I got the picture clearly. Fred as
Frankenstein, Fred the brilliant creator of the uncontrollable monster
flowchart. 'But what about Jane?' I said. 'I thought Jane was very good. She
picked up the program design ideas very fast.'

'Yes,' said the DP Manager. 'Jane came to us with a great reputation. We
thought she was going to be as brilliant as Fred. But she hasn't really proved
herself yet. We've given her a few problems that we thought were going to be
really tough, but when she finished it turned out they weren't really
difficult at all. Most of them turned out pretty simple. She hasn't really
proved herself yet -- if you see what I mean?'

I saw what he meant.

[0] [http://www.amazon.co.uk/Requirements-Specifications-
Software...](http://www.amazon.co.uk/Requirements-Specifications-Software-
Principles-Prejudices/dp/0201877120)

[1] [http://www.win.tue.nl/~wstomv/quotes/software-
requirements-s...](http://www.win.tue.nl/~wstomv/quotes/software-requirements-
specifications.html)

------
akamaka
I've lived this experience, many times over, and the story is true at it's
core.

Some folks might dismiss this as a fantasy scenario, and sure, it's missing a
lot of details. In the real world, the lone programmer doesn't get to write an
efficient program for different reasons: the software design is locked down by
managers, there is fear of abandoning the poorly written legacy code, newer
programming tools aren't allowed because most developers don't know them, or
there is a sunk cost of an expensive software license that has already been
purchased.

The story is symbolic, but the lessons are universally true, even today. For
managers: conventional methods of judging productivity are unreliable. For
developers: few organizations will enable you to work optimally.

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

~~~
colomon
It's explicitly labeled a parable: "a simple story used to illustrate a
lesson." It's not meant to be literally true. The second programmer's
inexperience is just another reason why his boss judges his work to obviously
have been easy.

~~~
JohnHaugeland
Unrealistic parables teach unrealistic lessons

That a thing is a parable does not render it immune to disagreement on realism
grounds

Indeed if the defense is to point out that it's not meant to be realistic then
it's probably not just valueless, but of negative value

Parables are not a good way to learn in my opinion

~~~
colomon
The point of this parable is that neither company has any clue what the actual
value of the work done was. Alan looked like he was working hard and was
rewarded for looking like he was working hard. Charles looked like he was
goofing off and was rewarded for that.

Yet when you compare the results, Alan took 24 programmer-months to solve the
problem, and Charles took 3 to do it better. If the companies had some way to
objectively value the work done, Charles is clearly vastly better. But they
don't.

It's got nothing to do with the specific techniques involved. It doesn't even
weigh in on the reason for the difference -- is Charles brilliant compared to
Alan's normal, or did Alan just stumble and turn a simple task hard? That's
all irrelevant.

The point is just to illuminate how hard it is to know the value of a
developer's work. I know I've run into that repeatedly in my career.

------
edw519

      Day         What I Did        TotLOC
      ---  -----------------------  ------
      Mon  Prototype Possibilities     300
      Tue  Write Building Blocks       900
      Wed  Construct Major Content   1,700
      Thu  Add Features              2,200
      Fri  Refactor, Test, Deploy      300
    
      Customer: Looks great. Thank you!
      Boss: Only 300 lines of code in 5 days?
      Boss: How can you be more efficient?
      Me: I could take Fridays off.

~~~
raldi
I don't understand; your numbers add up to 5400, not 300.

~~~
EliRivers
The final column isn't LoC written that day; it's LoC in total. Friday was
spent refactoring (what we in the old days called "rewriting", before the
hipsters made it cool); taking the code that was already working, and making
it smaller, lighter, better.

~~~
frostmatthew
> what we in the old days called "rewriting", before the hipsters made it cool

Calling it refactoring dates back to at least the early 90s[1], which I'm
pretty sure predates "hipster hackers." If anyone "made it cool" it was
probably Martin Fowler[2].

[1] [http://www.ai.univ-paris8.fr/~lysop/opdyke-
thesis.pdf](http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf)

[2]
[http://www.amazon.com/gp/product/0201485672](http://www.amazon.com/gp/product/0201485672)

------
Periodic
I dislike this strongly. It is attempting to demean a group of people without
really giving them a fair chance. It exaggerates and vilifies the "enterprise
programmer" while lionizing the young-but-inexperienced smart programmer. It's
a very common theme here on HN. It's playing into the narrative of the young
entrepreneur that can drop out of college and build the next successful start-
up. The fact is that most people in that situation will fail the first few
times as they gain experience. People who can operate like Alan, though
obviously Alan does not deliver results, are very valuable in a company.
Systems have a tendency to get more complex and you will need people who have
experience dealing with that complexity, managing it, and reducing it.

Let me address the parable a bit more directly.

The parable is very hard for me to relate to because to me it seems like the
two characters are cherry picked such that they're vastly different in terms
of skills. It looks to me like Charles is either much better than Alan at
design or got lucky. I think the only wisdom that can be gleaned from the
story is to not over-complicate your design. Charles and Alan both spend time
upfront designing their code, but it seems that Charles came up with the
better design and saw the simple kernel of the problem. That's the only real
difference between the two. Alan saw a problem that needed a lot of work and
specs to get right, but Charles saw it was actually a very simple problem.

I would say the lesson is to make sure you understand the problem well enough,
but Alan is an experienced guy who still couldn't figure it out, so it must
have been a hard problem to know how to work with in the first place. Maybe
Alan was working defensively to make sure he had all his bases covered in case
the design turned out to be different than he initially anticipated. I can't
say.

~~~
ploxiln
This is indeed a comment-baity article. It is fiction, those two people didn't
really exist and do those things. It gets programmers/developers riled up -
because it's so believable.

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?

------
jorjordandan
A lot of people seem to think this is a story about programming. It's not.
It's about perceptions. A good programmer knows that a certain portion of his
work is managing perceptions. This is part of a skill-set known as 'soft
skills' and will get you farther than a perfect understanding of monads.

------
rkachowski
The issue that seems to be overlooked here is the objective value of solving
the problem itself. Instead it focuses on the developers and their rewards.

A does a thing, it takes a long time, solves the problem and he becomes System
Analyst.

C does a thing, it's shorter in both time and effort, and he leaves the
company a year later.

What about the value produced by the solution?

It's clear that if a single (inexperienced and poorly communicative) developer
can produce a satisfactory solution in a fraction of the time of a majorly
architected approach then the first view (A) is overvalued.

The moral of the story seems to be something about how huffing and puffing,
self-importance is rewarded over a thought out appropriate solution to the
task at hand.

How about going forward in the story? A sequel-sequel?

At Automated, their unrealistic approach to planning and development, and
their focus on titles and rewards led to bloated and unmaintainable software,
where everyone in the company fought to make something "smart" that
demonstrated their intelligence and worthiness of being rewarded - the problem
specifications being nothing more than a means to achieving this.

At C, Charles either gained the experience necessary to understand the reasons
for communicating efforts and planning to the rest of his management and went
on to design appropriate solutions in another company, or he decided that
being rewarded for his efforts was more important than solving problems and
gaining domain experience and joined the above.

------
anodari
I know it's a parable and the objective is to send the message that "customers
value complexity". In the enterprise we see lots of news where a business
spend millions in a certain solution and we sometimes think it was overspend.

But I see another point why the story reflects the reality in some aspects:
experienced developers tends to overengineer a problem, and I recall the
'hello word' joke about programmer evolution. But at the same time, the
novice, rarelly will deliver a good sollution in the first time.

In my point of view, the simpler solution, will just work, could have lots of
technical debts and could be hard to scale, while the complex one, could turn
costly to support. Its very hard to find an optimal point between both.

------
beloch
This brings to mind the maxim, "A job, no matter how small, will grow to fit
the time and resources available".

~~~
sidcool
Well stated. I will jot it down for my next meeting with my manager :)

~~~
javert
Shhh. It's a secret. Use it to your advantage, don't tell your manager!

In all seriousness though, your manager probably won't take kindly to hearing
your advice about project management.

------
danschumann
If there is a second sequel to this story, it's that the one guy goes on to
start a successful company, and the other guy is entrenched in the politics of
his company.

I think this would be a better comparison if space invaders was left out. Or
perhaps if it were, "he scribbled for a while, then played space invaders,
then scribbled some more.", as opposed to him starting with nothing but space
invaders. The other guy began by inventing problems rather than solving them.

It comes down to, a direct, though outwardly puzzling, solution that is apt
VS. an indirect, political, frustrating(for everyone), bloated, slow solution.

If it weren't a programming department, and it were two different companies,
survival of the fittest would kick in, and the better faster guy would be more
successful. And, it has. We now learn from the successful companies that are
similar to the space invader guy and it doesn't seem so weird. The fact that
people were catching on to this idea in 1985 is pretty striking.

This is anecdotal and doesn't really teach the bigger picture. It's also not
encouraging, as it doesn't lead the user to the correct path of action.

It really needs a second sequel where the space invader guy goes on to be
wildly successful to be a good story.

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

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

~~~
gwern
APL should've been much more popular if prestige by intimidation was a major
factor.

------
kazinator
I can see exactly where Charles went wrong. Here is how the story should have
gone:

Charles implements an entire interpreted language with garbage collection and
an incomprehensibly coded virtual machine. Everything is documented and works
flawlessly at that level, however. Nary a bug can be found by anyone
experimenting with the language.

Charles writes the program in 30 lines of this language, which appear fairy
simple on the surface, but rely on some deep semantics (that Alan's team
doesn't even comprehend, for instance, let alone management, without
studying).

In this case, nobody can dismiss the problem as being something easy that a
junior programmer can solve, and Alan's team look like troglodytes from the
Dark Ages. All the more so because their buggy, incomplete program is over
2500 lines, while Charles' language fits into 2300.

:)

------
rumcajz
Rarely (unless you are working on your hobby project) you get a chance to make
program simple. There are inherently complex requirements that can't be
changed for political reasons, complex legacy interfaces to conform to et c.

Interestingly, most programmers seem to think that inherent complexity doesn't
exist, i.e. that any requirements can be translated into a simple program. The
result of this approach are leaky abstractions that later on cause much pain
to the developer and anyone maintaining the codebase.

------
sidcool
Quite an interesting article. The best part is that the article does not
judge. It simply lays down facts for us and leaves the opinionated part onto
us.

~~~
smasuch
I thought this was a fictional story.

~~~
thaumaturgy
It might be the most fictional story ever written about programming.

It's completely ridiculous.

~~~
javert
I don't think it's ridiculous at all. Have you ever worked in the defense
industry?

~~~
thaumaturgy
Yes, actually, I have.

So this story isn't ridiculous because it applies to a niche that it never
mentions?

------
moca
I have seen this kind of problems many times in real life. By start writing
design doc and prototype code from very beginning, you demonstrate effort and
progress. You most likely get hold of the project and eventually deliver it
along with all the incremental complexity during the process.

On the other hand, if you spend 2 months iterate through the requirements and
alternative design choices, you are far more likely to come up better design,
but your manager (or the entire company) would have no patience to watch you
thinking in your head. As the result, I have seen software designs could have
been 10x or even 1000x better, but most people prefer to get something out
first (this is especially necessary for startups).

Another random comment is LoC per day. I worked at a few large companies. The
statistics show the residual code is about 6-16 lines of code per business day
per software engineer. A lot of time goes into design, debugging, testing,
iterations, redesign, refactoring.

------
motters
This is a parable about whether you really understand the nature of the
problem, or not. If you do then you can produce a concise definition (i.e. a
better program in fewer LOC) and if you don't then it can get much more
complex. It's like the difference between trying to make a machine fly by
making wings out of feathers and having it flap, or understanding the
principles of aerodynamics and making a fixed wing out of canvas.

However, for most non-trivial problems understanding everything up front isn't
possible. To know what works you may need to create prototypes and iterate,
abandoning things which don't work or which end in a hairball of complexity
and getting opinions from testers. In that situation just intuiting a solution
and then typing in the code won't work and the more formalised process might
work better.

~~~
TheOtherHobbes
The parable is really about the nature of corporate politics and the art of
perception management.

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.

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

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

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

~~~
swatow
I realize that I was referring to number of LOC touched a day, not change to
the total codebase size. I'm not sure what the first poster had in mind.

For reference, I count myself as writing about ~40 LOC a day for a greenfield
project (which I spend about 50% of my time on), measured by total codebase
size.

And no, it is not HTML templates, although it is a fairly verbose language.
And I do all the things you describe in your first paragraph.

In my experience, a good programmer is almost always a fast programmer, and
non-trivial programs usually require a lot of LOC to get the job done.

------
eludwig
I think it's actually a great little story because in the end, everyone got
what they wanted.

The lone programmer did his work, got paid for it and left, hopefully to find
a company with a better fit.

The team was hired and got paid to do their work and, while doing so, created
a process that the company felt comfortable with. Perhaps they are still
working there today.

Everyone seems to have taken what they needed and got what they wanted.

There are an infinite number of ways to slice a thing. Choose one and figure
out if it works for you. This applies to both sides, the worker and the
management.

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

~~~
black_knight
While software architecture certainly is an art, I would not say it is unique
in that aspect among the fields you mentioned. Both engineering and maths
should be considered art in their own rights.

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.

------
speby
How neat to see this little article pop up from 1985. Professor Neil Rickert
was one of my computer science profs while I was at Northern Illinois
University. He was a pretty solid teacher and beyond a doubt, knows his shit
in and out. Definitely a highly respected professor within the computer
science ranks. He's now retired or Professor Emeritus now, I believe.

------
collyw
And if the specs change after the code was written (as usually happens in real
life), who's code would have been easier to update? There is a reason
experienced people may put more effort in to certain areas they junior
programmers, they will have an idea what is likely to change and when.

------
thaumaturgy
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?

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

~~~
thaumaturgy
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...?

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

------
gpvos
Thanks. I have read this many years back, but could not find it anymore.

------
PhoenixWright
I can't wait to get out of software development.

I'm just a couple of years removed from uni and I'm already planning my exit.
My first corporate job was a huge eye-opener. This type of stuff left and
right with zero career advancement and complete disdain from corporate.

I'm not even thirty and I plan on retiring and starting my own business (tech
or other) by the time I'm 40. The only good thing about tech is that I can
actually find a job and that the pay is above average giving me the
opportunity to take the money and run!

It's a complete shame too because I enjoy solving problems through code. I
love learning about new technologies. But everywhere I look software
developers are completely screwed, absolute wasteland of an industry.

~~~
aidenn0
This comment is more for others than for you, but there are good companies out
there that are engineering focused. Almost none of them are corporations in
which "software" is just one division of many,

------
scott_w
If we pretend this was a real story, Charles's manager should really have
spoken to Charles about playing Space Invaders for 2 weeks straight. While
Charles may be getting some valuable thinking time in, I can imagine he's also
pissing off his colleagues who will feel they're working to support a guy
messing around.

The exact nature of that depends on Charles, his manager, and the company, but
it is possible to have those conversations without diving in and accusing
Charles of goofing off.

Also, the manager made a huge mistake in judging the code based on what he
saw. He should have spoke to Charles about this and tried to glean some
insight into how it came to look so easy. If I'm speculating, the manager was
looking to punish Charles for his behaviour and went about it completely the
wrong way.

~~~
ricefield
And that is why this is a parable—not a real story, and not intended to be
read as one.

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

~~~
cshimmin
I think you missed the point.

~~~
vegabook
...though the idea that "engineers want to produce art, while management wants
to sell stuff" has a lot of truth, and does have oblique relevance to the
post, in the sense that Charles' "goofing off" was about thinking about the
best way to abstract the problem and write it elegantly and concisely.

