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 -> 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.
I'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'm pretty sure that is not actually case.
Having done this a few times, when switching from old to new, the new framework would have a DB agnostic ORM. What works nicely is building the models, duplicate templating, getting a mirror working. Shut down the old site, and then it's possible to go on with normal development.
So, it is important to consider rewrite and redesign as separate goals.
However messy it may be, there's usually a lot of domain knowledge to be learned from such a legacy codebase.
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/frameworks just for fun or to explore and compare.
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.
Look at antirez - he is a rare example of a guy of deep understanding before code.
If there was some catastrophic, quirky failure of backup, and you could only save either (a) all your production code, sans test, or (b) only your tests, which would you rather save?
Assuming you've written thorough tests, they win out over code every time. The tests remove all ambiguity.
I'm reminded of a story that illustrates the point:
A young woman always cuts the ends off of her pot roasts before cooking them, following her mother's example. One day, she asks her mother why they do that. The mother doesn't recall, so she asks the grandmother. The grandmother looks at them both, shrugs, and says, "When I was your age, we lived in an apartment with a very small oven. We had to cut the pot roast down to make it fit!"
Tests alone provide little value to anyone. At least if you had the production code you could keep it running in its current state while you added back those important tests bit by bit.
Most of the tests wouldn't be needed as good code tends to be churn-free. Finally if you wrote the code TDD style, then writing tests for even the hairy bits would be "easy" compared to rewriting the whole system.
I wholeheartedly agree with this! The big challenge is that you have the patience (and the patience of the management) to understand the old system thoroughly before starting to write new code.
A good rule of thumb is that reading code takes at least as long time as writing code.
The second one is "the second system effect" from Mythical Manmonth, which says that when people re-design a system (or a language) they tend to make a kitchen sink from it, throwing in everything that comes to their minds (hello, Rust?)
There is also a common sense notion that a sequel for the sake of a new version is usually much worse than the original.
What is common of them all? It seems that still the best writing is rewriting, but only if your understanding of the details has been grown and now you have less clutter in your mind. But if you do a rewrite without much thinking or just to get shit done, there is a high probability that you will fail.
NB I've only had one project go badly wrong that way and I guess it was a useful learning experience :-)
Especially try to avoid "big bang" switchovers.
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.
3 month in after launch I was going to rewrite it again, I decided, this would'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....
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't do that, it's insane, I was insane but not anymore.
I was just really crazy and stupid to pursue my own vision of what the solution would be when in reality I lacked the experience (I started with barely knowing how to code).
I had the same experiences last year. There wasn't even a single person who knew the 'old system' on the whole. A receipt for many detours and much extra work.
Lots of solid advice and patterns for approaching thing sort of thing.
- Mixing refactoring and new feature.
- Introducing new technology
- Changing behavior of old code that were not directly concerned by the rewrite
...
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.
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.
