in reply to Private module organisation

You have two options. Both equate to the same thing.

1. Refactor.
2. Rewrite.

First thing you need, is a full understanding of the system. Feature freeze and map out everything. Every module, config file and any other dependency. Next, have a good understanding of what an ideal version of the system would be. This includes where things should go and what the system will look like.

Here's the easy part. You make the old system look like the new system. You start to do 1 of many things.

  1. Run both systems in parallel, the old and the new as it is being written. This means data gets written to two places, and then parts of the software become deprecated as new ones are put in. This is not so much cut by product, but function.
  2. Build the new system and old system concurently, providing hte new system to a very small controlled set of people. You can address problems, and things you won't need as the new system grows. Think of it like beta testing. This cuts across some percentage of your customers.
  3. Go in a cave, rewrite the system, forget the old, then cut over. This takes a long time and is very hard to estimate anything about. Prone to a lot of people being pissed at the end due to things broken for everyone. At the same time, a lot more poeple could be happy with the new system.
  4. Stepwise rebuild. It sounds like the first part, but kinda is, yet isn't. It is akin to rewriting newest nodes while RAT stays in place. One shouldn't affect the other as they are being rewritten serially. Perlmonks is more commingled in its feature division that other systems, which are larger and have more parts, such as a bank's financial system.

Uh, step 3, profit. That's about it. Other than the above, prof'ing and patching, there's not too much else you can do.

----
Give me strength for today.. I will not talk it away..
Just for a moment.. It will burn through the clouds.. and shine down on me.

Replies are listed 'Best First'.
Re^2: Private module organisation
by tbone1 (Monsignor) on May 17, 2005 at 14:02 UTC
    Uh, what sporty said. Sometimes you just have to step back ten yards and punt. Otherwise you wind up preserving junk and cruft that keeps slowing your development and operations as time goes on. The real problem is convincing management of this, many of whom either don't get it or don't care since they won't be in their positions that long. We're getting close to that point here at work, and we're doing a few 'stealth', fill-in projects to start the ball rolling while we can. It's not an ideal solution, but it beats ignoring the problem and hoping it will go away.

    --
    tbone1, YAPS (Yet Another Perl Schlub)
    And remember, if he succeeds, so what.
    - Chick McGee

[reply]
      Management is always a tricky issue. jeffa, who was told by maverick eduardo, told me, which is true: people who like you are more likely to listen. It's a psych trick that involves disonence and grouping I think. Anyway, gotta have management like you and listen to a reasonable argument.

      After all, systems are like cars. If you do the upkeep very well, replace parts as they break down, use better parts when applicable, any system can become standard for the company. Otherwise, people start using the wrong oil's, the cushins look like crap, rust starts to occur... bleh.

      ----
      Give me strength for today.. I will not talk it away..
      Just for a moment.. It will burn through the clouds.. and shine down on me.

[reply]

In Section Seekers of Perl Wisdom