Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Wait until MJD finishes his Program Repair Shop and Red Flags book, then order it and give it to the developer in question, so that in the future, they may write better code.

    —————— • ——————

    For the moment, I would ask: is this program still being edited? If so, it’s justifiable to take time to fix it, so give some code reviews; point out a handful of improvements that will have the largest effect. Do this iteratively, so the programmer can actually learn, instead of being overwhelmed by a slew of changes that would give him the impression that you are doing this just to show him how much better you are, not to teach.

    If the code is currently “finished,” though, there is probably no justification for working on it. In that case I would wait until it needs bugfixes or features. “Refactor as you go” – which means when you’re not going, you don’t refactor, and when you are going, you always take the time to clean up any existing mess a little (to make your changes easier if nothing else). Do not clean up code just for the sake of cleaning it up; not only is this hard to justify to business types, it also does not actually add value. The next feature request is as likely as not to require you to undo some of the cleanup. (For management purposes, consider the concept of technical debt [martinfowler.com].)