Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Sunday June 18, 2006
01:17 PM

What's in a name?

[ #29945 ]

If you're familiar with chess, you might know the old saying "a player with a bad plan will beat a player with no plan". As a general rule, once you commit to a strategy in chess, you should keep up that strategy unless diverting from it gets you a very clear gain which your opponent cannot overcome. A player who plays for the moment with no eye towards the overall game will rarely succeed in the long-run. Conversely, a player who only looks at the long-run will often overlook tactical opportunities and can be outplayed by a player who knows this weakness. The great majority of players, though, play for the moment. They might have an idea of some long-term goal, but they're constantly looking for short-term advantage. In chess, those players are generally known as "losers" because, well, that's what they do.

In programming, we see something similar. We take a bad system, we start refactoring, but in the interest of "getting it done now", we only get it halfway done. This is then repeated many, many times despite the intention of gradually migrating to the "better way". Then others come along and start to work on this system and they're seeing a hodgepodge of things like &some_func and &some_func_new. Some code uses the "old style" and some code uses the "new style" but it's not always clear when it's appropriate to use either.

To be fair, a company doesn't often have the resources to simply rewrite everything. Budgetary, temporal and resource constraints all conspire to keep a "half-baked" system half-baked. However, without disciplined management and programmers, this is a very tough problem to overcome.

Since this problem is one we see constantly -- knowledge that code needs improvement and many partial efforts of dealing with this -- I think it needs a name. Once something is labeled, it's easier to talk about and deal with. Does this common situation have a name? It would strike me as odd if it doesn't, but then, perhaps it's so terribly common that it's taken for granted rather than explicitly dealt with.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I see tons of similar decisions being made for new code as well.

    Decisions which are clearly made with little thought towards the future.

    Trouble is I don't see an obvious name for the overarching term other to invoke Back to the Future's "You're not thinking 4th dimensionally!!!".

    That people can be suckered into trying to beating the Halting Problem, or a design decision that is clearly subject to a Tragedy of the Commons doesn't seem to me to be a general problem, they just don't see far enough ahead.

  • Hi Ovid!

    I just returned from work when I saw your message and I can understand it and relate to it. There may be one of the so-called "anti-patterns" [] about this, but since there are quite a few of them, I'm not sure if it will be easy to find. I'm not much of a pattern/anti-pattern freak myself (as I like to think of good solutions to problems when they are needed, and not waste precious memory remembering tons of patterns), but there are people who are more into this kind of thing. I can try asking so

    • Well, I talked with my "patterns" guy. He said that one may find what you're describing in the "Big Ball of Mud" [] article that describes how a software project goes on to having a lot of bad code, possibly in terminal state. (Note that I have yet to read it)

      As for my "lazy refactoring" or "just-in-time refactoring" - he called that "continuous refactoring", or at least thought it was a good name for it, and said refactoring should be done at small, atomic steps. You can consult Joel on Software's Rub-a- []

      • You've nailed it. Originally I didn't think about that because I had the incorrect impression that a big ball of mud primarily referred to a reasonable system which decayed with age. From reading the first bit, I see that the BBOM also refers to what I described. I think I need to reread that article again. Thanks, Shlomi!