The Worthlessness of Code

by James Turner

In my (painfully) long career as a software engineer, I've often run across the attitude that code has intrinsic value. You see this frequently in the industry when 'code reuse' is used as a metric of efficiency. At several companies I've worked at, old and badly bit-rotted products have not been rewritten because "we've invested umpty-umph million dollars in that code, we're not just going to throw it away." This whole attitude is bull-doodoo, and here's why.


2008-03-25 17:35:20
What's more valuable than the code? The documentation that explains why the code is the way it is.
Anthony Towry
2008-03-25 22:40:42
This post really stomps on the belief that an organization can hire an outside vendor to build a game changing system and still get appropriate bang:buck.

I love it.

2008-03-26 10:18:00
I think you're making three assumptions here that I've never actually seen work in practice.

First, that most developers can read code at any speed at all. (If so, it's probably at least three orders of magnitude slower than writing code.)

Second, that the value of the experience embedded within the code is sufficient clear and obvious that developers can extract it from somewhere, whether that's a comprehensive test suite, copious design documentation, or the code itself. (It's going to have to be the code itself.)

Third, that your organization can afford to make no effective forward progress on the project for as long as it takes for the rewrite to reach feature parity with the previous version.

Having the original programmers available ameliorates some of the potential problems, but even still you're asking people to remember the details of conversations they had months or years earlier while examining long-maintained and likely well-modified artifacts of those conversations.

2008-03-26 11:19:30
Eh. The value of using software such as compilers, database systems, web servers, xml parsers, compression routines, arithmetic libraries, encryption services, etc., should be completely obvious. It doesn't mean anything that nobody wants your for-loop.
Dan Sickles
2008-03-26 12:19:34
I'd prefer ongoing refactoring to rewriting but The Innovators Dilemma tells us that we have to consider it. If we don't, someone else will.

2008-03-26 12:36:24
chromatic: the first assumption you name is scary! Especially in relation to an old post of Erik Naggum's I just read (which argues that in code, as in English, reading voraciously is a far more necessary prerequisite for good writing than writing obsessively); and in truth, I am sure that reading code to a point where you understand it takes less time than writing new code to a point where it works perfectly.

Moreover, surely the argument that most programmers can write faster than they can read is a strong argument for not letting them near existing systems, and *only* letting them work in the relative sandbox of new development...? ;)

2008-03-26 12:45:59
* Actively maintained codebases can get better with age
* Rewrites are very expensive - its correct to be extremely hesitant to throw away large systems
* Nowhere do you mention regression test suites
Michael Feathers
2008-03-26 13:38:51
I think the opposite is true. Code has too much value. You can write a large application with a set of top-notch programmers and then use it for years having people do patch-work maintenance. Imagine what it would be like if all code disappeared within a few months of writing it. You'd have your rewrites and organizations would be forced to keep talent.
QUiet Please
2008-03-26 13:50:25
I am pretty sick of peasants coming along and making these claims. You have no evidence, you provide none and you provide an assertion that is obviously wrong. Go look at all the dependencies in your debian distribution. Do you see how reused code is? Do you see who requires who? If you do a study of those projects, how many were thrown out? Not a heck of a lot.

See I've attempted to provide some evidence. I haven't gone and done it, but at least I tried. You didn't.

2008-03-26 14:36:38
Documentation!? Ha!!! Who told you that there are companies who are willing to make the resource investment (not to mention the willingness to accept the delayed deployment date) required to produce real, usable, "valuable" documentation?????

What bizarro universe are you from? Toss in a few cryptic comments every few lines and that'll do just fine thank you.

James Turner
2008-03-26 14:52:02
QUiet Please:

You can't take comments made about business practices with proprietary code bases and refute them with data drawn from a massive open source project.

Open source and for-profit proprietary are two entirely different worlds from a cultural perspective.


2008-03-26 15:15:59
I'm going to side with Joel on this.
2008-03-26 20:14:18
Oh wow. The author clearly has zero experience developing or maintaining large-scale/mission-critical systems in "the real world".

Pick any topic. Take an extreme view to get clicks/page-views. Crank out another useless diatribe to meet his word/column quota.

This has got to be one of the more useless and ignorant articles on software engineering I've read in the past year--and there's plenty of pablum out there.

James Turner
2008-03-26 20:36:58

Actually (and not to get into a "mine is bigger than yours" match), I've been in the industry for 28 years, have worked on some fairly massive (70+ mil, 100 person) enterprise mission-critical applications.

I've also seen, far too often, incredible unsupportable, bloated with redundant code, Piece-of-poop codebases that never get cleaned up, and then when you have to do something like take the leap to a SOA or SaaS architecture, you end up with paralysis because no one wants to touch the code anymore.

I won't argue that deciphering poorly written and documented code is a slow and laborious process, I once had the treat of refactoring a 600 line method in the Apache Jakarta codebase, it took a week. But if companies made an effort to keep their codebases documented and commented, it wouldn't be nearly as much. With all due respect to Joel, the value in discovering some screw case in IE and putting in a patch ISN'T the patch, it's the knowledge that there's a screw case and a way to fix it. So, in your file, you put the fix in, and a comment explaining what it is fixing and why. Then, when the rewrite comes, the engineer comes along, sees it, says "Aha, I must deal with this," and either grabs the code wholesale if it's in good shape, or refactors for better quality if it isn't.

I never said (and in fact explicitly said the opposite...) that you couldn't use the existing code both as reference and code resource. I'm not talking about a Chinese Wall, I'm talking about a top-to-bottom merciless reexamination of the codebase periodically, with no sacred cows.


Stefan Nolde
2008-03-26 20:37:02
Context, ladies. The article is a very good observation about unreflected "best practices", and the occasionally bipolar responses show that fast and efficient reading REALLY doesn't seem to be a popular skill in software engineering. Refactoring of existent code is a topic handled. A resume for the lazy is: This is about reuse by principle, not about maintaining code bases.
With a good modular concept and well defined interfaces, the occasional rewrite of parts of the code base is as acceptable as just keeping things that work. Just make sure to have the right developers available when your code gets outdated with te change of technology.
The main point is: no matter how good the original code, no one who wants to assure quality can afford to save on the expertise.
Ken Hansen
2008-03-26 20:48:14
"When management talks about the value of code, they’re really talking about the value of the experience that the engineers gained by developing the code, as expressed in the code."

I disagree with this statement/assertion - the value of the code discussed at the management level is the intrinsic value in the resulting work said code performs. The value of the engineers that created the code is only considered in terms of the cost of a replacement engineer to maintain the existing code.

I've worked *around* major software projects (not as a coder), and it was the non-programmers that always spoke of the "value" of code reuse - the programmers I saw almost always worked best when left alone to craft their ideal solution to a given problem with as few constraints as possible - asking them to spend time trying to find code snippets to use in their solution is counter-productive. The projects I worked around were major, multi-million dollar telcom infrastructure programs used by all the regional bell companies - big, serious, projects with very demanding requirements - and I was floored to watch them sit around and figure out ways to count KLOC and divine "function points" to satisfy management productivity reports...

Ingo Karkat
2008-03-27 01:18:02
"The problem is, most companies let the value walk out the door (either through layoffs or attrition)"

... or through transitions to another group of developers. Sometimes management actively destroys value for the sake of cost reduction by transferring code ownership, often to teams in so-called "low-cost geographies".
I'm right now experiencing this for the third time in three years.

2008-03-27 02:43:01
This is the pipe-dream of most engineers.

The real world however refuses to conform to the dream. If you a programmer in any "old economy" company, you realize they will absolutely not spend any money to rewrite or even refactor. There is simply zero return on investment; after spending loads of cash, they will get a system with the same business functionality

2008-03-27 09:34:26
That code *is* worthless, and not just because it's trivial in an HLL. With no documentation, other programmers will find it faster to write their own than to read yours. With no tests, other programmers won't trust that it still works (and refactoring is impossible).

You say the value of code is the people that know it, but do you remember every line of code you've ever written? When you need to understand something, do you always ask the original author?

Sure, people are (usually) the most valuable thing a company has. But that doesn't mean code has zero value. Preventing programmers from leaving is, in the general case, impossible: I could get hit by a truck tomorrow. Writing tests and documentation is easy, and part of my job. Why are you trying to substitute one for the other?

2008-03-27 10:23:12
As many people are pointing out, expecting a business to accept a large rewrite or refactor as its own project is unrealistic. Then again, I don't think the article suggested that.

Refactoring needs to be built into every project that touches code. In a particularly moldy system you might spend 50% of the project time refactoring existing code. It's often a base necessity to add new features in the first place.

It's stupid to spend extra time working around the old code for some inane concept that it's "someone's" code and modifying it would devalue an investment. There's much more value to refactoring (usually simplifying) the old code to work with the new features.

Skylan Hill
2008-03-27 12:25:53
I am not a uber-programmer, nor have I been on huge projects.

I think what you may have glossed over unintentionally is the individual peices, such as your for-loop, take place in a larger machine with spinning whiz-its and clunking doo-dats. That larger scope takes far more time to develop. I agree with you that the code for a for-loop, or within a relatively side-effect free function is entirely replacable, that's not true at a higher abstraction level.

How long would it have taken you to develop the class or module this is based in? And the interfaces it exposes?

One is merely mechanical, and the other is highly cerebral.

Perhaps the difference is your example is concerned with "how it's done", and the real value is in what is done or why.

At least that's my opinion, and I'm welcome to it.

2008-03-27 15:12:19
What you say is BS. You are missing the forest for the trees. Individual segments of code may be easily re-written, but the whole program cannot easily be recreated (for any sufficiently large software system). Specially when you are talking about something that has seen several revisions and fixes for numerous issues over the years.
jeremiah foster
2008-03-27 15:21:38
Computer software is useless without the hardware, network, and engineers who implement it. This is why good engineers make so much money - they are a valuable commodity.

One of the interesting things about Free Software is that it has made mountains of proprietary code worthless. Why? Because smart engineers do something cool to the linux kernel and everyone else gets to build on that as well, multiplying the effect of innovation.

James is absolutely right; code is worthless, smart engineers are what is valuable.

2008-03-29 05:45:06
Interesting points, and I agree in most of them. As many others have pointed out, no companies are willing to pay the cost for good documentation. But another point is who would want to write it? Do you know anyone who likes to write documentation and if so, is it really any good?

2008-03-29 12:06:56
Tom Harrison
2008-03-29 14:51:41
Thank you. THANK YOU! The notion that code depreciates is dead on.

Several commenters made a reasonable point that there are things like libraries, compilers and so on that are designed for re-use and are re-used, and while true, I see your article focusing more on the application code: the code that glues together all the libraries into something useful for doing tasks. The code in applications doesn't last.

Having passed 20 years writing commercial code, I have observed how other developers seem to value the code itself. It becomes personal -- a form of expression, perhaps. But that's silly. Code realizes its primary value only when it executes in some useful way in a larger application.

We have looked for the re-use of code for ... ever. It's the wrong thing to re-use: we should look for reuse of designs, patterns, realizations, and habits that make applications come together more quickly and reliably.

I have also observed is that it takes a great deal more effort to develop reusable code for an application. It requires that the developer create an accurate abstraction of the problem being solved, then do a reasonably good job implementing it, then having other callers who actually do reuse it. But in 9 out of 10 cases, not all of these things happen, and you end up with needlessly complicated code designed to be a Swiss Army Knife when all you needed was a letter opener. And then the requirements change.

The effort of understanding the abstraction is worthwhile, I think. The effort of developing to support that abstract is not, in most cases.

I have considered my code "disposable" for a long time (and have had colleagues turn up their noses at it). But I usually get things done really, really fast, and so if it turns out that the business requirement wasn't specified perfectly, I can rewrite the whole thing again. And it's always better the second or third time. It's very, very liberating to code this way.

This is not to say that there are not cases where things should be wrapped up into a nice library or module or API, but it's the exception.

I am willing to accept that the best outcome of whatever I write is that someone will like the idea and rewrite it, better, in whatever the cool technology is that day. That is code with value.

2008-03-30 10:37:22
Great related Spolsky article:

They [netscape] did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.


Also, without a comprehensive test suite, there's almost certainty a full rewrite will be a disaster.


Cheers --


2008-04-02 01:26:57
Great provocative article. The code you provided is an example of low value, possibly no-value, code, precisely because it is not usefully re-usable, is deficient (your null numbers point) and has no obvious utility. You are right: code has no intrinsic value. However that is like saying words or symbols or raw materials have no intrinsic value. The value is derived from using them in meaningful, formalised ways to construct useful artefacts, whilst also recognising that over time the value of the artefacts so constructed can become of lower value, with the level of obsolescence related to design.