Well, billable hours are a good thing, but you have to ask yourself if you want to be trying to `polish a turd' for the next 6 months, or if it will be less painful and less smelly to just squeeze some of your own out?
I suppose the trick is to make sure that the heavy refactoring that is needed won't impact on the customer. Either way they're going to have to pay for it to be re-written, if it's not all at once (as in re-doing it) it'll be re-re-rewritten as you take out the quotes in favour of heredocs, then the next guy replaces those with Templates, and the guy after him as to refactor something on another spot, to allow a new function to be added.
I've been patching an unspeakable system for the past 9 months, and you know what? it's not far from where it was when I started, because of all the little odd off-by-one cases, and the wierd if-this-if-this-if-this conditions thrown about in it.
If you want a well defined behavour and a nice set of clean interfaces, get a good unix programer (i'm sure you are a fine example of this, Firefly258, garrison et al) in and start again.
Even if you refactor everything, to be perfectly readable and clear. you'll still be stuck with the initial design (if you believe they designed it) -- and how good can a design by these people be?
slash rant.
Not that I'm bitter about that
@_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;
| [reply]
[d/l] |
Politics and economics are a programmer's worst two adversaries, it's the case all over. They also indirectly and negatively affect ergonomics, a programmers friend. Like yin-and-yang, a balance must be struct between the two opposing forces for there to be happiness and harmony all around.
Present a good solid case to the client, to make him wholly aware of the benefits a complete overhaul can bring over the long-run, the facts backed up by figures, the advantages and disadvantages of a new approach and the advantages and disadvantages of the existing approach. The number one reason to push for a revision is the side effects of poor legibility having a negative impact on the programmer effeciency (and other effeceincy indirectly) with the current code is simply unacceptable. Number two would be the long timeline between a proposal (for code modification, feature addition, etc) and the time of delivery of complete solution. Convincing a client that a certain radical approach is mutually benefecial is always a very hard feat, especially if they are worried about you leeching on to "billable hours" or are doubting your programmatic competence. A good, solid and sincere argument is necessary and it's clear you have one, you just need to compile the facts and figures that make the decision-making non-programmers understand the benefits they seek to gain.
<-->
perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er
| [reply]
[d/l] |