 |
Breaking
eBusiness and Search News |
|
 |
Reuse Or Write New?
Sometime last summer I was involved in a fairly complicated Perl project. It was one of those "Well, it's just like the thing you did for X, but now we need it for Y and Z".
So.. obviously there was going to be a lot of similarity between the code already written for X and the new code needed for Y and Z. Moreover, the programs all run on the same server and have some input sources in common. Therefore it would seem to make sense to make one program that reads configuration info for its outputs (X, Y and Z) and behaves accordingly.
So that's what I started doing last summer. Unfortunately, shortly after starting that, something changed, and there was no longer any requirement for Y and Z. Somebody ran out of money or had something more important to attend to or whatever: I was told to stop, so I did.
A few weeks ago, Y popped up again and I was asked to finish up the work. I consulted my memory, took a cursory look at the code, and thought that it looked pretty darn close to finished. I was also lead to that conclusion by some emails from last summer where I had indicated that it was getting close to testing time. So I ran through and made a few last minute adjustments and turned the beast loose, expecting at least reasonably good results.
How wrong I was.
True enough, I had written the great bulk of the code. I had taken the "X" code, wrapped it in a big loop that read configuration data for X, Y, Z or whomever, and hacked at it to have it use the configuration variables. And truly it really was very close to being ready to test. But it wasn't quite as ready as I thought it was. No output. No results. Just the whistling noise of a Perl program crunching data but never fulfilling its purpose.
At first, I thought that the failure to produce output was normal: these programs have to accumulate input from internet sources and sometimes the sources aren't ready, or there isn't quite enough raw material to produce the final output. I knew it could take a day or two before the scripts could produce anything, and (as usual) I had plenty of other fish to fry, so I put it out of my mind.
Until the customer called to remind me that it had now been three or four days and there was still nothing being produced.
Arrgh. I looked more closely at the code. Oh, for crying out loud: I had left in short-circuit code that I was using during testing. The script couldn't even reach its output sections. I mentally kicked myself and removed the short-circuits.
Checking back two days later, I was honestly surprised to find the darn thing still wasn't working. How could this be? I had no time to look at it then, but yesterday I settled in for a final wrestling match with the code.
It turned out that there was a large section of processing that had NOT been parameterized for the loop. It still had lots and lots of "X" specific code in it. Worse, I wasn't entirely clear on what the purpose of some of that code actually is. I think some of it was only there to correct some early misunderstandings where bad data had found its way into our accumulations, but I'm not 100% sure of that.
I had re-used "X" code both to save time and of course to avoid mistakes: if "X" is working as desired, and "Y" is similar to "X", it makes sense to use "X". But.. I wrote "X" a long time ago. It wasn't years and years ago, but long enough that I only have a vague idea of what it does.
Oh, yeah, that's what comments and documentation are for. Except we never get to that stuff, do we? Not enough time, no budget, just make the thing work. The "X" code isn't entirely strange territory, but it is strange enough that I feel wary and troubled in hacking it to accept parameters.
Sometimes it really is better to just throw away all the old stuff and start over. It may cost more, but then again it may not: while the script is now producing output, I'm not certain that it is the right output. I could spend a day re-reading the original correspondence about the "X" project (assuming I could find it), but a lot of that was verbal communications as it was being written, some of which appeared as brief comments in the code but I am not certain all of it did. So I'm left with turning it over to the client with a strong warning that they have to look closely at the results to be sure they aren't horribly broken.
I'm not happy about that. Yes, of course the clients always have to bless the output: it's ultimately their responsibility to check that I have translated their wishes into rows of properly formatted output. But when I'm writing from scratch, I have a much fresher understanding of what the results should be. Right now I feel like I've thrown a bunch of stuff in a grinder, dolloped it out on plates and am standing back wondering "is that what this recipe is supposed to look like?"
Well, let's hope it's not too far off. The customer will look it over Monday and maybe it really is ready to fly. We''ll see.
*Originally published at APLawrence.com
Add to | DiggThis | Yahoo! My Web
Technorati: perl, developer
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
