Geek Answers Handbook

What questions should I ask when trying to determine whether to rebuild the system?

I participated in evaluating whether we need to rewrite several of our systems from scratch or if they should be partially rewritten, or if they should just continue, as is with the corrections above.

To better assess the situation, I was wondering what questions should I ask myself and others to help determine the appropriate actions?

+6
architecture
source share
6 answers

In general, I found that rewriting code tends to be a problem (it is expensive, time consuming and involves the discovery phase, which makes the first system better).

However, here are a few questions to ask:

  • Will basic refactoring be sufficient? You will learn from the system assessment whether the central problems will be deeper than the code. If the problems are in the code base (and not the technology itself), I prefer refactoring.

  • To what extent can the current system be checked? The ability to test is of great importance to extend the life of any system module, because the code being tested is usually easier to extend and maintain. This also applies to # 1.

  • Finally, whether the value afforded by the rewriting will justify the effort. This is a business matter, of course, but one that a developer can and should do.

In most cases that I encountered, there was no answer.

+3
source share

I would recommend you read Things You Should Not Do, Part I. He makes a strong argument for not remaking.

Money Quote:

It is important to remember that when you start from scratch, there is absolutely no reason to believe that you will do a better job than you did the first time. First, you probably don’t even have the same development team that worked on version 1, so you really don’t have “more experience.” You will again make most of the old mistakes and introduce some new problems that were not in the original version.

Perhaps you should ask yourself if you know the system enough to fix problems without rewriting it. If you do not, you can safely say that you do not know the system well enough to remake it from scratch.

+8
source share

Finally, you want to achieve something when you rewrite the system from scratch. You must ask yourself what do you want to achieve? Do you want to:

  • Reduce the risk of creating a system with old technologies.
  • Cost reduction: too expensive to maintain

You can do a break-even analysis to see when your new system begins to pay. In my opinion, you should be able to reduce the re-registration of the system to costs and be able to see that the new cost is less than the old.

+1
source share

  • How long can you not deliver? What is the time for what reasons you underestimated the previous projects? How much time can you afford in the worst case scenario?

  • How much labor is currently being spent on maintaining the existing system? Do you have this workforce available in addition to people developing a new system?

  • How can you make sure that you are not re-creating the same system with the same problems? Avoiding obvious architecture errors is usually not enough.

  • Can you compete / survive if you do not have the resources to improve the current system?

Even if "Refactor and Repair" means that ultimately, replacing most of the existing system, it means that all resources are ressources to the ONE system, not two.

+1
source share

I suggest that you need a context for discussion, and the best that I am familiar with is found in Martin Fowler's book “Refactoring”. For me, the real question is: "Is this application refactorable?"

The first concrete guideline will be “Is it written using good OO design principles”? If not, usually you need to either put him in support of life, or start. If so, the book will provide a lot of help; and in my experience there is good reason for hope.

+1
source share

in the following order:

  • Does it work correctly?
  • Is it fast?
  • Is it easy to maintain?
  • Is it easy to spread?
0
source share

More articles:


All Articles