APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Grokking the Source

© September 2006 Anthony Lawrence

At When Understanding means Rewriting, Jeff Atwood has an interesting observation:

if you actually observe what software developers spend their time doing, you'll find that they spend most of their time trying to understand code

Jeff's post and subsequent discussion is actually about rewriting code vs. trying to understand it, and that's worth reading, but first I just want to concentrate on the brief fragment I quoted.

Understanding code isn't always easy. Fred Brooks might have been the first to note that:

Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.

    -- Fred Brooks, The Mythical Man Month.

I'd put that a little differently: it's easier to deconstruct the workings of the black box if you can see the inputs and the outputs.

Ahh, but those inputs and outputs.. for example, I could look at most driver code and never comprehend it simply for lack of knowledge concerning the chip(s) it is twiddling bits in and out of. Even arming myself with a spec sheet may not help that much as you usually need to understand one chip in the context of the other things it is intertwined with - without the grand system overview, you can't infer intent.

But let's say that we can grok the inputs, are aware of the exceptions, and have a firm grasp on the desired results. We now return to Jeff's hotly contested assertion that it is sometimes easier to rewrite than to work over existing code. It's "scratch vs. patch".

The arguments for reuse are both obvious and compelling. "Don't reinvent the wheel", we say, and there's also the fact the the "wheel" may be a highly complex, tightly optimized piece of work that took someone much brighter than I many hours of painstaking attention. Not only would I be wasting time rewriting such code, in fact I just might be incapable of writing it at all.

But sheesh, we know that, don't we? Of course we do. Those arguments are from extreme positions. I think Jeff and the comment writers who agreed with him weren't thinking of rewriting wheels or (usually) Fourier transforms. No, we're more usually looking at some ad hoc thing that is going to take a lot of effort to understand. Maybe the original author loves OOP and you don't. Or vice versa. Maybe you just don't like the variable names, or the code is just too clever or not clever enough. It's hard to understand or it's easy but it makes you grind your teeth. Whatever. I agree with Jeff: sometimes it is just easier to write the whole darn thing yourself, from scratch, soup to nuts, reusing nothing.

That said, I have to add that I am also in complete agreement with Joel Spolsky's "Things You Should Never Do, Part I", which details all the reasons why you do NOT start from scratch. That these professed agreements seem in irresolvable opposition is an illusion: again, I think we are talking about different things. Rewriting Netscape may have been a bad idea, but rewriting a Perl script that transforms some data into other data probably is a good idea; and is especially so if reading the old code gives you a headache.

I think of it like architecture. Sometimes it would be silly to tear down a building and start over, but sometimes starting with dynamite is really the only path. So is it with software: there is a time to patch, and a time to scratch.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Grokking the Source


Inexpensive and informative Apple related e-books:

Take Control of iCloud, Fifth Edition

Take Control of Upgrading to El Capitan

Take Control of Numbers

Take Control of Pages

Take Control of Preview

More Articles by © Anthony Lawrence

Fri Oct 2 16:25:16 2009: 7045   Mark

If you're re-writing, or not re-writing for good reasons then all is well. Something I've seen many times in my company - a person at siteA(usually me) writes some tool to do some needed task, then another person at siteB, knowing full well that the utility exists, writes a completely separate tool to do the same task. But what's even worse, they don't write in such a way that it will work at siteA due to differences in the network topology.

I call this, or maybe someone else called it, NIH - Not Invented Here.

How about when you re-write your own tool? Many years ago, I spent about a month writing a complex tool(in Korn shell) to automate our build system - many bells and whistles. After it was all done, the painful truth was that it was too slow. My boss agreed to let me re-write it in perl - a language I'd been meaning to learn but hadn't. Another month later, the tool was done, I learned perl and it was fast enough - barely. Several months later, it was lightning fast after learning how to use a RDBMS.

Not sure how relevant that yarn was but Internet ink is cheap.

Fri Oct 2 16:38:03 2009: 7046   TonyLawrence

Internet ink definitely is cheap - so we never mind comments (unless they are completely off the wall).


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

If you understand something, it is probably already obsolete (James Burke)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode