 |
Breaking
eBusiness and Search News |
|
 |
Grokking The Source
At http://www.codinghorror.com/blog/archives/000684.html, 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.
*Originally published at APLawrence.com
Add to  Del.icio.us |  Digg |  Yahoo! My Web |  Furl
Bookmark WebProNews: 
Receive
Our Daily Email of Breaking eBusiness News
About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
 WebProNews RSS Feed
More Expert Articles Articles
Contact WebProNews |
|
|
 eBUSINESS
RESOURCES |
|
|
 |
|
| About
WebProNews |
WebProNews is the number
one source for eBusiness News. Over 5 million eBusiness professionals read
WebProNews and other iEntry business and tech publications.
WebProNews provides real-time coverage of internet
business.
Free Email Newsletters:
|
|
|
|
A.P. Lawrence
