Ha. You have been on great projects. One after the other. Have you even seen bad code before? I bet you have always worked with a great team.
-
-
-
Just because a project is great and the user-facing aspects beautiful, doesn't mean the codebase is perfect. I've been on amazing projects with terrible codebases.
-
Do you really believe that Rob?
The reason I can speak so confidently about these things is because I *have* seen a ton of bad code (I’ve even been the author of a lot of it) and I’ve also many times made the mistake to rewrite instead of reworking & refactoring. -
I'm actually doing that right now for
@chibistudioapp, the code for the standalone app was mostly in AppDelegate because at first it was supposed to be iMessage-only -
I agree ... before anyone knows whether a project will be “great” or not there are already 10,000 lines of code in AppDelegate
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
At some point refactoring feels like you rewrote the whole thing.. I hope not many do full rewrite from 0.
-
A lot of companies rewrite from 0 - as in "File > New Project" in Xcode
The rewrite by refactoring approach you mention is so much better, since you can do it piecemeal and continuously deliver while doing it, and you still end up with a shiny new implementation in the end 
-
I only saw it once, after company moved the development in house and the project was so badly written that it was impossible to maintain and provide bug fixes, not speaking of new features. I mean code duplication with minor changes in multiple places and etc.
-
Probably still better off refactoring. I was recently at a company that re-wrote from scratch including sync between new/old DBs! product was at a stand-still for 10 months and new product was arguably worse.
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
Solid logic! One edge cases I recently heard of - is no one would be brave enough to go into the codebase to fix bugs / add features. It was beyond salvation

-
In my experience, many teams jump to that conclusion way too quickly though. Basically "someone else wrote the code" == "it's beyond salvation"
But yes, in extreme cases a complete rewrite may be warranted 
-
Definitely agree! Did you ever see that at Spotify? From my limited experience, impact-driven companies usually discourage rewriting just for the sake of rewriting. Definitely fell into that trap working at startups prior. With my own code!

-
At startups, just do a rewrite on the sly... or, just move your codebase to a different language to force one.
-
My favourite was swapping databases for the new-hotness.db™
-
Best DB is NoDB
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
I successfully pitched a re-write of Shazam (which shipped as v5) circa 2013. Drastically improved stability, performance, UX and maintainability. There was a massive reduction in code volume through making better use of the evolved iOS platform. It just made sense.
-
I agree that rewrites are usually the wrong option. But blanket rules about such things, applied without taking the specifics into consideration rarely serve well. Some codebases are so fragile even the smallest refactoring hoses stability. This was one.
-
My first app was totally unmaintainable and as a result refactoring was more dangerous than re-writing from scratch. As an added bonus I got to re-write in Swift from Objective-C
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
I think it can be good marketing when people hate the existing app. Why anyone would announce it for an already-popular app is beyond me ¯\_(ツ)_/¯
-
This. Also sometimes this is exaggerated for marketing. "we rewrote the app from scratch" == "we redid the UI"
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
লোড হতে বেশ কিছুক্ষণ সময় নিচ্ছে।
টুইটার তার ক্ষমতার বাইরে চলে গেছে বা কোনো সাময়িক সমস্যার সম্মুখীন হয়েছে আবার চেষ্টা করুন বা আরও তথ্যের জন্য টুইটারের স্থিতি দেখুন।
