Rewriting vs Incremental Improvement?

Question

In the place where I work I am implementing new features in a legacy system. The system in question was written around 2008.

Some problems encountered in the system:

• Database tables with 90+ columns
• Information redundancy. (Duplicate data in some tables)
• No reference keys in tables (Foreign Keys)
• Absence of some entries. To list for filtering is given a select nome_campo in the main table. (Data are entered only by importing from another system)
• Lack of compatibility with other browsers. Only works in IE 7
• Permission system with bad architecture. (It is common to see bugs in which a user gains access to a feature that should not)
• System main screen has ~1300 lines of PHP code + HTML + Javascript

Given the above scenario, it is more prudent to continue with incremental improvements or it is better to try to convince the client of a rewrite?

If the option is to go to a rewrite, what arguments can I use to convince you?

Answer 1

^{I have my doubts as to whether this question should remain open or not. I gave you the benefit of the doubt because I think a good answer can help other people with this despite the risk of being based on opinion. At least I’ll make it clear what is opinion and what is my experience.}

The customer will pay?

Does the customer want to pay for one thing or another? He wants to know the benefits of an option or another that in the background does not bring anything useful directly for him. The benefit will be more yours and may reflect on what he will receive, but he cannot perceive this, and has no way of proving to him that one will be better than the other unless he does both, measures them and shows them to him. I don’t have to tell you how insane it would be.

It may seem obvious that one is more expensive than another and depending on who speaks it will say that one of them is more expensive. I have my doubts.

Do I need to say that each case is a case? I need to stress that maybe you will only be sure if you did the right thing after doing?

Does not rewrite!

Joel Spolsky has a famous article to never rewrite. Joel is great, he was responsible for one of the best Microsoft products when Microsoft made very bad products. He’s respected by almost everyone. But he’s wrong too. Jeff Atwood has questioned him before and probably this website exists because of this :)

He cites the example of Netscape. After everything went wrong, it’s easy to say that they shouldn’t have done it. There are certain software that really shouldn’t be rewritten, ever!

But an internal software, mainly a software that is a website, that has architectural problems, should not?

If you think about it, Joel is right. Never, ever rewrite a start-up software. Doing this is 100% wrong! If anyone who has experience with development interprets the text correctly will see that there is no question.

And make a new software that meets the same needs?

That’s another thing! Trying to rewrite a software that needs to be compatible with the old will always bring problems and will always cost much more. Point!

Making a new one that meets the same needs, possibly others, without concern for compatibility is something else.

Microsoft rewrote its browser (twice, one of them taking advantage of what already existed but wasn’t hers). Not everything, but a lot. But it is another browser, it is not rewritten. The old one will be as legacy. Whoever needs compatibility will be with the old one. Who wants improvement goes to the new (almost everyone). She rewrote several technologies such as the Entity Framework and parts of the . NET Core, created a new API (UWP) for Windows, just to name a few examples. I’m not saying I should always do this, especially her because she should meet the needs of a lot of people and not something specific.

If making new software from scratch was always bad there would only be one of every kind on the market. Sometimes we need to compete with ourselves not to be out of competition.

My experience shows that trying to rewrite is not that bad, although it will always cost more. But I’ve done it a few times in different ways and the worst experiences were when in addition to rewriting, new things were added before rewriting finished. Doing both doesn’t work.

On the other hand convincing someone to pay for a rewrite that will bring no immediate direct benefit and will only create the basis for improvements is something almost impossible. I have already received promises that this would happen and the project stopped in the middle of the way for lack of immediate results.

But if you can make a new software and can present some results that can gradually replace what is being used everything can be different.

It may seem like I’m telling you to make new software. That’s not it. Only you can know what’s best. And if you have never done it, you don’t know whether it will work or not. Even if you already have experience you won’t know for sure, you will only minimize the risks.

Personally I practically only worked with software already written. And whenever I could I rewrote, I did a new one, I didn’t even try to improve the existing one. I made a new one every chance I got, a new one with no regard for the legacy. It always took work, brought me problems, it was tiring not only to redo but also to deal with users, but in the cases I worked it was always possible to do this. And every time I could do it was very rewarding.

My case

Some will say that it is more professional to do what the customer wants. I personally only work in what I like, I don’t work in what gives me money. Money is a consequence. I know that not everyone can do this.

I’ve always taken really bad software, really bad. Not only badly written, using bad and outdated techniques, but they all had serious architectural problems. Evolution was compromised. I’ve always gotten software full of side effects which is one of the worst problems that software can have. Making an analogy with a car, it was common that to move the arrow if not push with a special touch he opened the door. You can’t work with software like this.

I have already resigned when I could not arrange these things (making a new software). But it is something personal.

Not everything is black and white, things are gray, unexpected factors interfere. We’re not robots. Behind a professional there is a person with human characteristics and this needs to be taken into account.

Which is more expensive?

I don’t know. As I said before, you can only know by doing both. Even so I have my doubts if you can be sure. If it is done one way by a team and then the other way by the same team it will already be more experienced with the project and it will be easier to do the second, even if this is done incrementally. If done by different teams, the results are not so comparable, each has its own characteristics, computation is exact by itself, the project is human like any project.

Many will say that the rewrite is more expensive. But not if you don’t have to worry about compatibility, if you can make a much better architecture, use better techniques, do it in a way that you dominate and do it much faster. It’s more expensive anyway?

I think other than. But I couldn’t say even if you hired me to give an opinion and I had access to the whole project and I knew well the ability of the team that will make the new software.

Yeah, team capacity is important, not everyone will know better.

If you refill it, can you take advantage of something you’ve already used in another project? That counts. You can hardly take advantage of something already done in a legacy project but you can start the project from scratch with a ready-made skeleton based on a project of yours already executed. It can make a huge difference. And it can be a good argument to sell the idea. Even if you exaggerate on the advantage :)

Will this project produce material that you can reuse later in other projects? So maybe it pays for you to subsidize the cost a little bit, not pass all the cost of the rewrite on to this client.

I always speak as a customer because I’m used to it. In your case the cost translates into time. And probably the risk is the "client" (your employer). If you can’t, it makes convincing a little more difficult.

Your case

It seems that you have a very bad software. This helps to decide. I don’t think, I may be wrong, that you need to maintain compatibility. Can you deliver parts that show there are advantages? Can you show at the very beginning some tangible things, how to work in all browsers, for example? It could be something simple. Can you improve usability? Can you put a killer feature? Are you sure you can do something really better? You have experience for this?

The customer will probably take longer to start paying for something, maybe he will only pay when he has everything he had. Can you wait? If it takes too long, whose risk is budget overflow? If it’s his, are you sure he’ll pay? If it’s yours, you can afford it?

I find it more risky to make a new one. You will hardly have a client who understands the advantages of this and everything that will happen in the process. The chance of the project stopping in the middle is relatively large (each client imposes a different degree of risk and you will probably only know too late).

It is easier to "roll up" the customer by making improvements over the existing one. In the long run it will probably be more expensive. But the customer won’t notice. We live in a world where right doesn’t matter, perception matters.

Convincing the client

A professional salesman would do a better job convincing the client that he should opt for the rewrite.

I don’t know how to convince a client, especially without meeting him. I think the biggest argument, presented by Gabriel Rodrigues, is that the new software can be used by more people. But this is a seller’s argument. No problem. Incremental improvements can achieve the same thing, and maybe you can deliver results first. So I as a technician do not know what arguments I can use unless my experience shows that in the long run rewriting can come out cheaper in cases that the current one is very bad and that the new one does not need to be compatible, just need to solve the same problems.

Another way to convince, shown by Chambelix, is to demonstrate that current technologies are outdated, have problems, etc. Maybe it is exaggeration but it is a way to argue with laypeople. I don’t know how far you can go with this without crossing the line of ethics (if you need to overdo it).

Try to provide yourself with data that shows you the advantages of doing it the way you think best. If you have difficulty getting them is already a warning, but not a guarantee, which may not be so advantageous.

But there is a great way to convince the customer to choose the one you think best. Give a closed budget with equal amounts. Even if you have to make a long-term contract with monthly values but don’t show that one can be more advantageous than the other. Then the choice is yours. And the risk too. I would do it. Reflect to understand what is best for you.

Want to take a chance? Give personal guarantee that it will be cheaper to rewrite. I don’t know if you have that credibility inside but it is a way.

Another way: I would say to show what other experienced people say. I would say to show this post. But then you will read that there are no guarantees. Who manages the project - even if informally - does not like to take risks and reading this he will see that there are risks, I would never say no, so I do not know if it will help.

Finally try to show the difference between rewriting and making a new one, rethinking, clearly showing all the visible improvements possible (the invisible ones are difficult to sell) and how difficult it would be to achieve them with the current code.

Completion

Anyway, I gave you some allowances. It’s obviously your decision and you need to be prepared for everything to go wrong whatever the choice.

Answer 2

I work at a billing software company that uses software written around 2004 and I’m developing the new version.

Companies need to know real information and experiences of other companies about how best it was to spend a good time on development of a "new" application.

I’m going to suggest some metrics that you can get to explain to your client, all of them are based on current problems regardless of what scope you approach.

1. Reach more customers, this metric can be simply explained by the current reality of the system which is to have compatibility only with IE7 and show the possibility of making a responsive application can be accessed both from laptops as well as tablets,mobile phones and other devices.

2. Present a time that the developer spends on media to solve a certain problem with the current version and a possible reduction of that time adopting another practice, this case is easily seen by the amount of redundancy in your DB.

3. Item 2 also applies here, in adoption and improvement in the time of the developer to work, one of the good practices that I adopt and have a file for each, HTML, CSS and PHP, all of them well organized in one Model-view-controller - MVC.

Your client definitely wants the system to make a good profit and customers to like it, to show that your changes could cause this and you’ll get approval to rewrite it.

Complementing what @bigdown quotes:

"But if you can make a new software and can present some results that can gradually replace what is being used everything can be different."

Thinking of new ways to solve the same problems your software solved can be extremely heavenly, but it can also be a shot in the foot.

In the study of the interaction of People and Computers the approach of a new solution starting from both low-layer and high-level improvements that is the client’s vision.

In the Customer layer try to improve the usability system. has to be easy, simple is intuitive to use.

Answer 3

As I understand your question. If the system is from 2008 it means it was developed with the reality of 2006 forward. More or less.

A lot has changed, many basic PHP functions are and have been discontinued, so if no update has been made, it will be suffering. As of August 2006, PHP 4.4.4 was already available, so it still depends on whether the server has this version.

Not to mention SQL reporting to project development and maintenance techniques and already now even by your own sanity... because I’ve also been through this and I know what it is, will not miss anything in putting your point of view.

In my opinion it is preferable to start from scratch if you have the budget for it. Implement a MVC decent and technical Object-Oriented I don’t need.

Altering the design and putting more patches might even call you into question as a professional, because at the very least... it’s been tampered with by you.

For a company and for those who decide what matters is less costs and development times for yesterday... but in real life quickly and well not to whom, I have always heard say.

When you talk about IE7... I think it’s easy to show that technology today is different and that today the browsers used are totally different in the technology they embrace. The design focuses very much on simplicity and versatility of formats, so if present a solution that innovates in these fields certainly who decides will look at the spectacular result and ask you what will be necessary to achieve it.

When I want to take a technical solution forward, but who I have in front of me does not understand very well the solution because in fact is not a programmer I usually elaborate a real layouts in order to put in the hand of who decides the difference and looks that results "almost" always.

Answer 4

The client doesn’t know what a rewrite is. You who have to make the decision and budget a price, then the customer will accept your price or not, what you are doing or failing to do does not matter to the customer. What matters to the customer is the price of the product, the result within the deadline and in many cases the price of maintenance as well. You have to guarantee it for him.

Something once happened to me that might serve as an analogy. I went to a dealership to buy a car, then I saw the price of the car and I found it very expensive, the seller tried to explain to me saying that the price of the car was very good and besides the other part of the car was produced in a city of a state of Brazil, the engine was manufactured in Argentina, I don’t know what part came from I don’t know what country, the assembly of everything was done in another state of Brazil even further, and that in the end I was not going to pay anything for all this logistics! Look how advantageous that is? And he said that if I had to pay for the freight of every little piece that moved up and down the price of the car would go up even more, then I was going out on the profit actually.

After he explained all this to me I asked: "And I with this?". At the end of the day we didn’t close because the car was too expensive, and it doesn’t matter to me whether the parts of my car already know the whole of Latin America or not.

That is, the customer does not have to have all the details of the implementation, he wants the product ready and wants as cheap as possible. If you go to work at dawn and pay more in the pizza that you will eat because at this time the motoboy charges more expensive, the customer has nothing to do with it.

In short, you have to pass on to the customer the budget, the deadline and the maintenance price. Whether you will rewrite your system or not is something you have to convince, not him.