Joel on software rewriting code

Lessons learned. Rewriting a system from the ground up is essentially an admission of failure as a designer. Lessons learned in rewriting software Rewriting code is a developer illusion, not the solution in most cases: When you are in trouble with your code, it is important to diagnose what is the issue exactly. This is just an illusion. In this case, always remember the fundamental law of programming.

Consider refactoring before taking a step to code rewriting: Targeted rewrites are useful to deal with the worst offenses in your code base.

For example, the loading of your software is so slow. But this only affects a small part of the project. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces.

This is a longer, harder, more failure-prone path than you expect: There is a fact that developers usually realize it after they miss the deadline: Everything takes longer time than you think. Be very pessimistic in your estimates about the cost of a rewrite. It almost always costs more and takes longer than you would think. There will be always a lot of complexity that will make the rewriting process harder and more painful. In the end, the possibility of failure is hard to miss. They just want to solve their own problem.

In their eyes, you are successful if your product fits in solving their problem. Otherwise, they are not using the product. This is too long in the world we live in today. Our product was still good enough, but users were complaining about no updates. Never stop maintaining a system that is currently in use so that the programmers can rewrite it.

During the rewriting process, the old code still needs to be maintained. Small updates and bug fixing should be given users while you are rewriting the old code. Otherwise, you will face losing your customers.

Involve users in the design process as soon as possible: Always show your current progress to your end users at regular intervals so that they can help you catch the worst offenses. It is important to meet your users as soon as possible. Their feedback will help you design a new product based on their needs. This will save you from having a complicated code base. Keep the teams working on the product synced: The product is not only about programming team.

Marketing, support, programming, design… Many teams work on it. Keep them synced by giving them regular updates about the rewriting process. In our case, we have dealt with many problems. For example, the marketing team was preparing our product beta campaign and they had to know exactly what was going on the product side so that they can prepare customers for upcoming product changes.

Sometimes we made some changes without informing them. And this caused them to prepare their campaign from scratch. Do minimal changes and small UX improvements. Due to his position, our product development was going slowly. Even small changes were taking several weeks, sometimes months. The point is to always keep moving. Never stop. Migrations should be slow and steady: Replace your original software with the new one when you ensure that the new one is ready.

Do it step by step. First, start with a small private beta group and ship your product into that group. Continuously collect feedbacks and crash reports, fix the bugs, iterate new versions and again the same thing. Follow this cycle until you ensure that your product is ready to go public beta. When you go public beta, feedbacks are going to be your best friend again. When you are sure that you are providing the same or better functionality as old software did, replacement can take place.

Release the new software for new users, and migrate your existing users to the new one. When to rewrite the code There are times when it is appropriate to do a rewrite. If I could have made a list about when to rewrite the code, this would be my list: Switching to another language or platform as in our case : The language is so old.

We optimize your Service Mesh built on Istio. Our trusted, hands-on experts guide you. Join a community of over , senior developers. View an example. You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered. Your message is awaiting moderation. Thank you for participating in the discussion. In growing trend of Technology being the back bone in most of the buiness companies, in the same way technical people need to know the business, I see a demand for business people knowing the technology becomes imperative.

So some of the design practices we use like refactoring, eventhough it goes not have any meaning to business, but I think that keep system little more stable and reliable than before. Those days of clear separation is fading way Collaboration with overall system knowledge is becoming mandatory for successful launch Interesting piece. I'm wondering how many have seen this movie before in prior lives? Team demands that they have to rewrite and gets approval to do so. Months in to the project they begin to realize how high they've jumped from and they are without a parachute.

Due to market pressures the product needs to be released to drive sales, revenue, or to stay competitive yet they are still rewriting plumbing and many of the core features in the product still haven't been added back in let alone any of the new desired features. With time running out before they hit the ground with a rather large splat they have no choice but to reach for the reserve chute Nobody is happy.

I've seen this movie at least 4 times unfortunately once on my watch many, many years ago and it always seems to end the same. Just sayin'. Now, I'm leading the refactoring of a on-line application, whose code hasn't been cleaned for more than two years.

Actually, I cannot help myself to consider to rewrite it at all, but finally I decide to control my step and divide the whole process into several rounds of local refactoring, and now the first one has been finished. It is more practical for me to collect resource and persude the business peoples that the risk is under control. In this case the first worries of the team will be delivering as soon as possible which will lead to a completely ignoring of code quality.

Still, sometimes you must switch platform for some reason. Then you have to rewrite. The thing that people don't always think about is that there are some things one should take with them from the old crappy code. There can be some important solutions and bug fixes that one can reintroduce.

Nice article, I am only missing some good arguments for the other side. Do they even exist? I am big fan of refactoring but it's not the panacea. Refactoring is incremental, therefore it is a linear process. Unfortunately, the development of software systems is far from being linear. It is actually quite non-linear and that means that some bad changes in the code are potentially irreversible or would be ultra costly. You are commenting using your WordPress. You are commenting using your Google account.

You are commenting using your Twitter account. You are commenting using your Facebook account. Notify me of new comments via email.

Notify me of new posts via email. Skip to content VibratingMelon observations from the startup frontlines. Jeremy Burton in coding , software economics , startups , strategy June 10, September 9, 2, Words. What tends to go wrong — Part 2 It gets worse.

What tends to go wrong — Part 3 Oh dear. Why does this happen? Should you EVER rewrite? Good luck. Agree, disagree? Please leave a comment.

Rate this:. Like this: Like Loading Tagged architecture engineering engineers rewrite software. Thanks for your thoughts. Thanks, Paul. Awesome article.

Please leave a Comment Cancel reply Enter your comment here Fill in your details below or click an icon to log in:. Email required Address never made public. Name required. Follow Following. VibratingMelon Join other followers. Sign me up. Already have a WordPress. Log in now. Loading Comments Email Required Name Required Website. Post was not sent - check your email addresses! As a corollary of this axiom, you can ask almost any programmer today about the code they are working on.

It is two pages long! None of this stuff belongs in there! All new source code! As if source code rusted. The idea that new code is better than old is patently absurd.

Old code has been used. It has been tested. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Back to that two page function. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle.

That LoadLibrary call is ugly but it makes the code work on old versions of Windows Each of these bugs took weeks of real-world usage before they were found.

The programmer might have spent a couple of days reproducing the bug in the lab and fixing it.