For a few years I was the Silicon Valley Necromancer, attempting to reenergize failing businesses with new technology. I was on the Delicious team at AVOS (2012-2013), whom acquired Delicious from Yahoo!. I probably know very little of the whole story...but...I can at least share some of the technical challenges that we faced.
I lead the team on the re-write that brought Delicious into the single page app (SPA) world. Most people wondered why we built the app from scratch again. The python codebase that the Yahoo! team managed, I am not sure if they started their version of the app that way or if the inherited it, but we concluded that it would be quicker to re-write the app as opposed to dissecting the exiting application codebase. This is the primary reason why stacks were canned, regardless of what others might have said. Many times rewrites require reducing features in order to build a new foundation. This is sometimes a good thing, and sometimes not.
A rewrite also gave us the opportunity to build the app as an SPA. While we made an SPA, React, Redux, Webpack, Gulp, etc. did not exist, and we definitely ended up spending more time than expected creating inferior toolsets due to the lack of options at the time.
Another major challenge we faced was that the database was sharded in such a way that if your username was "zebra" the backend would hit MySQL server 1, then 2,3,4,5,6,7,8,9, and finally 10 before returning results. If your username was "apple" you'd get a response quite quickly. I am not sure if we ever completed the migration into new shards/replicas.
There were also some random old API endpoints where we had to double encode periods in the url or the API would throw an exception. Obviously there was no documentation on for our treasure hunt to find which API endpoints had this major issue.
We didn't get any notice at AVOS before the team was moved off of Delicious to work on other projects. Perhaps we took too much time building the rewrite, or perhaps we realized there was no business model worth the time.
AVOS would later make a unilateral decision to move all projects to Angular, which was not a framework I believed would benefit my career development. I left AVOS when StubmleUpon called me and said, "hey if you can make Delicious a SPA, do you think you can make our app an SPA?"
Boy, I sure know how to pick 'em...
P.S. I will say that the Delicious team at AVOS was a very talented team and I am thankful for each day I got to work with them.
[edit] for grammar
[edit ii] Since it doesn't seem clear in the comments: I'd build Delicious differently today.
> For a few years I was the Silicon Valley Necromancer, attempting to reenergize failing businesses with new technology.
Users don't care what technology stack you are running as long as you don't lose their data. They care about responsiveness, ease of use, new features that make them think you have their interests at heart, since it was a mostly free product.
The underlying lesson of Chesterson's fence is especially poignant here: instead of commissioning a rewrite, investing in tools that would help your team make sense of the existing codebase so you could fix the technical challenges is a less risky strategy. It also allows JIT documentation of the codebase as you clean up technical debt.
Writing a too complicated front-end is probably one of those situations that I am getting into more often in the last years..
After some 15 years doing web dev, I'm starting to encourage SPAs more and more sparingly - only where they _actually_ improve UX and it's worth the extra work.
Sorry that your project didn't reach the potential that it should have. I really enjoyed using and working on Delicious. Some of us still believed it had a chance while working on it.
[edit] As hackers it's important to highlight & discuss technical challenges a project faced..regardless if those challenges had true relevance to the project's fate.
I lead the team on the re-write that brought Delicious into the single page app (SPA) world. Most people wondered why we built the app from scratch again. The python codebase that the Yahoo! team managed, I am not sure if they started their version of the app that way or if the inherited it, but we concluded that it would be quicker to re-write the app as opposed to dissecting the exiting application codebase. This is the primary reason why stacks were canned, regardless of what others might have said. Many times rewrites require reducing features in order to build a new foundation. This is sometimes a good thing, and sometimes not.
A rewrite also gave us the opportunity to build the app as an SPA. While we made an SPA, React, Redux, Webpack, Gulp, etc. did not exist, and we definitely ended up spending more time than expected creating inferior toolsets due to the lack of options at the time.
Another major challenge we faced was that the database was sharded in such a way that if your username was "zebra" the backend would hit MySQL server 1, then 2,3,4,5,6,7,8,9, and finally 10 before returning results. If your username was "apple" you'd get a response quite quickly. I am not sure if we ever completed the migration into new shards/replicas.
There were also some random old API endpoints where we had to double encode periods in the url or the API would throw an exception. Obviously there was no documentation on for our treasure hunt to find which API endpoints had this major issue.
We didn't get any notice at AVOS before the team was moved off of Delicious to work on other projects. Perhaps we took too much time building the rewrite, or perhaps we realized there was no business model worth the time.
AVOS would later make a unilateral decision to move all projects to Angular, which was not a framework I believed would benefit my career development. I left AVOS when StubmleUpon called me and said, "hey if you can make Delicious a SPA, do you think you can make our app an SPA?"
Boy, I sure know how to pick 'em...
P.S. I will say that the Delicious team at AVOS was a very talented team and I am thankful for each day I got to work with them.
[edit] for grammar [edit ii] Since it doesn't seem clear in the comments: I'd build Delicious differently today.