in reply to Best practices and financial applications

The reality is that the business side of the company will only release funds for patching code, not for doing wholesale rewrites from scratch. But we are hoping that over time we can adopt a strategy to improve the code in fundamental ways over the next few years.

It sounds, (on the basis of very scant information, I may well be jumping to the wrong conclusion), like you are trying to expand what is primarily a maintenance role, into something more. Whilst I fully understand that motivation, I've been there myself, I strongly urge you to proceed with extreme caution.

If you break something during the process of refactoring for the sake of 'improving the codebase', or 'fixing' something that hasn't been explicitly documented as broken--by the owners or users of the codebase, not you or your team--then your good intentions will not save you from their wrath.

Move cautiously. Get sign-off for rolling unassigned refactoring back into production systems.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"I'd rather go naked than blow up my ass"
  • Comment on Re: Best practices and financial applications

Replies are listed 'Best First'.
Re^2: Best practices and financial applications
by djp (Hermit) on Mar 30, 2010 at 06:59 UTC
    +++++ to this reply, in my opinion this is some of the best advice I've ever seen on Perlmonks.
Re^2: Best practices and financial applications
by cleverett (Friar) on Mar 30, 2010 at 19:54 UTC
    Mostly, we're happy with doing maintenance. And our number of outstanding defects is way down. But the code we have, presents another set of risks (mostly long term) we'd like to mitigate.

    We have a big commitment to release management here. We develop on one box, use another box to create and test release builds and do integration tests. After that, code migration and the DBAs run the release builds out to yet another platform for another group to do user acceptance testing, before anything goes to production. And, we try to keep a consistent environment all the way from development to production.

    I couldn't be irresponsible and keep my job, even if I wanted to ...

    And yeah, we have *everything* in a version control system. Actually we have 2: svn for day to day development and creating release builds, and a corporate repository run on another version control system that we commit releases to.

    Regression testing is dependent on test data. We have a test data library with 30 days of anonymized production data. I'm working on a tool to use files from that library as templates for generating a stream of test files for out daily batch processes, by changing some dates and numbers in them.

    The same tool should be usable for modifying another set of templates to create expected outputs. Regression testing should be straightforward from there.

      You are obviously well set up and ready to go.

      Then my next step--after running everything through PerlTidy to get a consistant layout, and making sure it doesn't break anything--would run it all through perlcritic.

      Or rather, I'd run one or two of the larger pieces of code through, and then manually cross-reference the output with the code, and decide which of its protestations are bogus, and work out how to turn them off. Once you've turned it down to the point where it is only bellyaching about things that you agree are worthy of note, then it would be a fairly painless process to then pass the entire codebase through.

      That would give you two things:

      1. An indication of where to start concentrating your refactoring efforts.
      2. A set of documented (PBP) reasons that you can take to management as justification for the refactoring efforts.

      Maybe that suggestion will go some way for my grandmother-eggs-vacuum thing. It's often difficult to access where someone is at from the wording of their questions.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.