Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^2: Program size and effeciency.

by exussum0 (Vicar)
on Jul 09, 2004 at 10:59 UTC ( #373099=note: print w/ replies, xml ) Need Help??


in reply to Re: Program size and effeciency.
in thread Program size and effeciency.

Or you'll get blamed for having to take a long time to perform the smallest change. I remember once dealing with such a system.. took me a week to change the price of something. People got all excited when I finally got it. Scary stuff.

One time, I did get permission to rewrite a piece of that system... you were right, people did get annoyed when new bugs came up. BUT, after the bugs settled, it was the fastest and easier piece of the puzzle to modify. Some time passed, and they were doing efficiency analysis on the system to see where they could improve on it. Turns out the part that got rewritten was skipped since it was the fastest part of the entire thing. :)

Yes, tooting my own horn, but thought I'd share the positive experience of rewriting, and the negative of not rewriting. There /are/ times when you shouldn't. Just not never.

Bart: God, Schmod. I want my monkey-man.


Comment on Re^2: Program size and effeciency.
Re^3: Program size and effeciency.
by demerphq (Chancellor) on Jul 11, 2004 at 17:19 UTC

    I've has an similar experience to the one you describe here. I need to make a simple change to a critical piece of code in the system I am responsible for after the coworker who wrote it had left the company. He had given me a walk through indicating what needed to be done, and essentially suggested it was a trivial change. Unfortunately time didnt permit me to do the change with him, and once he had gone it turned out that what he had explained was wrong. I spent a week debugging the code, tracing through the code, etc. And got nowhere. Changes I made seemingly did nothing. As I knew there were changes coming along that would be much more drammatic I decided that given a trivial change was turning it a huge effort the future changes would be signifigantly more difficult, and frankly not worth the time. End result I wrote a total replacment, in only a little more time than it had taken to decide the old code was unmaintainable.

    That replacment provided a strong foundation for the much more drammatic enhancements that came down the pike. The time invested in rewriting and restructuring the code paid off big time as the new code base is much easier to extend, and has been pushed far beyond any of the changes I had thought were coming. Had I persevered with the original code base and taken another week to get that trivial change in place the stuff that came after would be impossible.

    I think what the OP needs to do is present a structural argument as to whether the code base should be refactored. If the argument is convincing his boss will give him permission.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://373099]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (9)
As of 2014-07-25 07:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (169 votes), past polls