throwaway2k04

Neo4J

One of the major mistakes that are made in re-writes is that the developers writing the new code are not always the ones who created the original code. They see complexity, but don't know if it is accidental complexity ("tech debt"), or necessary complexity.

One example from my own experience was a team that inherited a service that had already seen a major rewrite/refactoring to be prepared for requirements that the old team knew with certainty was coming. The new team created a new service that barely covered the needs that the company had at the time, and claimed that the new architecture was flexible to cover any future need (without actually investigating the needs that were already known). When they were tasked with supporting the new requirements, the end result was more complicated and less capable than the old service.

I feel like the frontend community is suffering from the "eternal september" problem. Like PHP, it is very easy to get started so you get a lot of inexperienced developers writing very opinionated blogs that are shared with other inexperienced people who can't see the flaws.

In my previous startup they decided to develop their own design library from scratch. My suggestion was to start with an established library and just adjust the style to match our look, but they wanted full control and ownership of the code. 3 years later, most of them left for new jobs and the library only contains a very basic set of components.

This mindset was so different from the backend teams in the same startup. They preferred stable and known frameworks and libraries, and focused on the business logic. I had a feeling that the backend teams just got stuff down with little drama, while the frontend team was engaged in endless debates and rewrites.