in reply to Difficult code (Resolutions)

Any good response to your post will require significantly more information.

Here are a few questions to start with:

  1. How much code? Are we talking less than a few thousand lines, 20,000+, or somewhere inbetween?
  2. What type of code? Is the language still in active development?
  3. What are you skills? Are you capable of making reliable modifications to the code? Do you know the language well, or just enough to rename variables?
  4. Who owns the code Does it belong to a company or an individual? Is it open source? How resistant is the company to change?
  5. What is the owner's current focus Have they switched all new development to a different platform and/or language? Are they in the process of migrating any other code from the same eroa over?
  6. What is the purpose of the code Is it for a pacemaker or an mp3 player? What level of quality is required.
  7. How well does the code work? Have many bugs been found in the past? Are there an unresolved known problems? How extensively is it tested/used?
  8. How much other code is dependant on it? Can you change the interface? Is it so obscure that you can't tell what the interface is?
  9. How well is it documented? How much do you know about the code's purpose? The interface? Internal workings?

That's a start anyways. These things are extremely dependant on the details, carefully examine any advice that claims to be a silver bullet.

Best of luck.

Replies are listed 'Best First'.
Re: Re: Difficult code (Resolutions)
by xChauncey (Scribe) on Aug 21, 2003 at 05:26 UTC
    Good questions...
    1. We're talking about ~8,000 lines of code
    2. The language, although not Perl, is in active development, and we plan to continue developing in such (even though I am currently the only programmer at my company)
    3. I would consider myself of an intermediate skill level in the language, I am fluent in the available built-ins and can translate most algorithms that I find in other languages (and in general algorithmic notation) to the language at hand.
    4. The code belongs to my company, is not Open Source, and they are fairly resistant to change (as far as a change in language is concerned), but I have a fairly free reign over implementation as long as all design requirements are met.
    5. Everything is pretty stable in this regard.
    6. The code is intended for computer based training apps, so bugs are annoying (although as everyone, I'd prefer if there were none), but will not cause loss of life or property.
    7. The code as I got it is good beta code, although there were minor bugs. The main thing is the additional functionality that I am required to make, changes in existing functionality, as well as fixing existing bugs when found by our testers.
    8. It is a stand-alone app.
    9. There is little documentation besides the comments in the code itself (which reside in a range from good in parts to unhelpful/nonexistant.

      10. Thanks

[reply]
Re: Re: Difficult code (Resolutions)
by adrianh (Chancellor) on Aug 21, 2003 at 08:34 UTC

    Two more good questions to ask a new codebase are:

    • Are there acceptance tests? If not, how do we know what the application should do, and whether it is actually doing it. We should consider writing some.
    • Are there unit tests? If not, how do we know what each module should do, and whether it is actually doing it. We should consider writing some.
[reply]
[reply]
[reply]

In Section Meditations