
The Worthlessness of Code - O'Reilly ONLamp Blog - marcus
http://www.oreillynet.com/onlamp/blog/2008/03/the_worthlessness_of_code.html
======
phaedrus
I think at least one part of the author's argument bears examining: the author
says, "The cold reality that software companies try to ignore is that ANY
major piece of software needs to be rewritten from the ground up eventually."
He makes a good case for it, yet Joel Spolsky has this to say:

"... the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch." ... "There's a subtle reason
that programmers always want to throw away the code and start over. The reason
is that they think the old code is a mess. And here is the interesting
observation: they are probably wrong."

Link: <http://www.joelonsoftware.com/articles/fog0000000069.html>

How do you square the two observations? I think that since you can't
reasonably go down _both_ roads with the same project at the same time, one
doesn't really compare the results of one option to the _real_ results of the
other, but rather to the _imagined_ result we would have gotten if we taken
the other road.

In short, _neither_ rewriting nor endlessly patching is going to produce
results as good as we think we ought to have; both would be a major pain in
the butt. The devils always lie in the details, details you won't hit until
you try one or the other. I'm inclined to think Spolsky is closer to the
truth, but I'm suggesting it's not as clear cut as either position would have
you believe.

The other point of the O'Reilly article, however, is spot on: "most companies
let the value walk out the door (either through layoffs or attrition)"

~~~
edw519
"most companies let the value walk out the door"

That's why I (usually) like the "rewrite" option. I can't think of a better
way to learn what the program does than by rewriting it and getting it to
work.

As I've told many clients before, "It doesn't matter how soon we start, just
how soon we finish." Sometimes, rewriting gets you to the finish line sooner.

------
pg
Code is a hypothesis. But some of it might be done. I think I still use some
Lisp utilities I wrote in the mid 1980s.

~~~
marcus
Code you wrote yourself, especially generic libraries will always be useful
for you as long as you use it on a periodic basis. I have some C++ code I
wrote back when I was 13 in my first courses in college which is part of my
current startup codebase.

The question is would these tools be useful for someone else? Would these
utilities make other programmers more productive? Would someone pay you to buy
your code? (except for its didactic/historic/collector value)

I see "On LISP" goes for about 200$ on Amazon despite the fact that you
published it as a free pdf.

~~~
pg
Yes. The ones I still use are now part of Arc.

~~~
marcus
Touché

------
bumbledraven
He's got a point, but Peter Naur said it better in _Programming as Theory
Building_.

<http://www.zafar.se/bkz/Articles/NaurProgrammingTheory>

------
systems
Okay, at first, I thought nice spin! He has a good point!

But then I remmembered Cpan! Okay, so moral is if you document your code
create useful libraries you can save a lot of code from turning useless

I can also see, that in most work places expecially in IT departments of non
IT organizations many still don't use a single repository for their code or
document their code and projects, this is why many code just die when the
employee who wrote it leave

------
Tichy
Everything is worthless - trivial statements...

~~~
Tichy
OK, maybe I should have been more specific. Somehow that article really
annoyed me: "code is only worth 0.83$, because I can code a for loop in 30
seconds". Hm, not very convincing. "Code is worthless once the original
programmers are gone" - just a claim, without any statistical backing.
Personally I think it is conceivable to actually dig through somebody elses
sourcecode and understand it.

I wonder if such articles are just written for "karma whoring", or if they
really express a heartfelt concern of the author.

