Lessons learned from the big rewrite

My experience from doing rewrites is that if at all possible (and it usually is, even if you don&#x27;t think so), do the rewrite incrementally. For example, in the case described here, they wanted to switch rdbms, change up the schema, change the application level implementation&#x2F;framework and change the interface all at once. That&#x27;s a lot of risk to combine.<p>Maybe they could have started by refactoring the schema in-place (That is, within mysql and webtek). Then change from mysql to pgsql - still behind webtek. Maybe separating the change of webtek -&gt; django from the interface change is a bit harder, but you could still try to restrain your self as much as possible and then make a second iteration of the interface after the initial change.<p>I&#x27;ve taken this approach before, when migrating a big product and it worked quite well. It seems as a lot of extra work at first, but I&#x27;m pretty sure that is not actually case.

&gt; <i>The first thing I will do the next time is taking more time to analyze the old system thoroughly and write a technical spec what the new system should do. A simple &quot;What the old system is doing now&quot; as a spec for the rewrite does not cut it. No one knows what the old system is doing exactly so it is necessary to take the time to write a spec.</i><p>I had the same experiences last year. There wasn&#x27;t even a single person who knew the &#x27;old system&#x27; on the whole. A receipt for many detours and much extra work.

It is not that simple and comes back to the same old maxim - as long as the only documentation of what the system is doing and why is its source code, you are doomed.<p>If you have a written detailed guidelines of what you are doing and why, which design decisions were made and why, which data representation is used and why and what corresponding algorithms are and why, then one could re-write parts of the system in different languages&#x2F;frameworks just for fun or to explore and compare.<p>Coding or rewriting is second to deep, hierarchical understanding of hows and whys. This is how the most of programming exercises are designed - once you have understood how it should be, which results each procedure should return (wishful thinking and tests before code, to define domain and range of a procedure - ideas as old as SICP) then coding is the most trivial part.<p>Look at antirez - he is a rare example of a guy of deep understanding before code.

For those who&#x27;ve not already come across it I would <i>thoroughly</i> recommend folk taking a gander at Michael Feathers book &quot;Working Effectively with Legacy Code&quot; on this topic.<p>Lots of solid advice and patterns for approaching thing sort of thing.

To number 2 (Migrating the database is hard) I would also add that it is important to verify the integrity of the migrated database in some way afterwards. Even a simple assertion like &quot;the number of user accounts (or whatever) is the same in both databases&quot; will help greatly.

After spending 3months rewriting an huge module for our many websites, initially estimated for 3weeks at most, I can say that it&#x27;s easy to make mistake but also incredibly good for the company.<p>- Mixing refactoring and new feature.<p>- Introducing new technology<p>- Changing behavior of old code that were not directly concerned by the rewrite<p>...<p>Many things that should have been done after that. But, all I can say is if the company can handle this amount of work, it will always be a very good way to improve the quality and durability of the website.<p>Because if you simply rewrite code, there is a big chance that your company will assign to you, new task that are not related at all and you will never be able to introduce these feature.

I have an issue with iframe perf test. It is very reckless and a waste of user bandwidth. One can reroll user requests from web server access logs and it would be a controlled perf test with real user behaviour.

Lesson 1: Don&#x27;t ever attempt a big rewrite?

For testing performance i would recommend <a href="https://github.com/buger/gor" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;buger&#x2F;gor</a> (i&#x27;m author).

Any drawbacks of #3?

I rewrote my product 6 or 7 times in the past 6 years. 4 of those years were written in isolation by myself. 1.5 years I worked as a developer which I HATED and fired from (refusing to work excessive overtimes and as a result impossible to find a job in this competitive labor market) and working on my product again. I open sourced the old code that I &quot;threw&quot; out to start all over.<p>Technically, never reached market until 5 months ago. I have of course, launched after each time the product was finished but would give up due to being burnt out etc. An entire year spent starting from scratch which would be my 7th attempt.<p>3 month in after launch I was going to rewrite it again, I decided, this would&#x27;ve been my last attempt in the software business. I decided that enough was enough, this is it. I ALMOST rewrote it again but having done that 7 times already, instead of doing that, I just ripped out a lot of code, made architectural changes and reused what I could, whatever was tested. 8 times a charm....<p>My lesson learned from past 6 years pursuing insanity, restarting from scratch means you will have to solve the same problems again and again. A blank canvas is NOT a solution. Don&#x27;t do that, it&#x27;s insane, I was insane but not anymore.