Ask HN: What practices can we use to avoid overengineering in our projects?
About a year ago, I joined a web dev team that at the time seemed very close to an ideal work environment that you only see in books.<p>Every good practice is implemented: strict version control using git flow, standarized linters, unit and integraton tests that are required to pass to get code in our repositories, code review with a minimum of two approvals required, and a long etc.<p>Over time, however, we&#x27;ve seen the project slow to a crawl due to the amount of overengineering that is commonplace: If a new need arises, it&#x27;s usually met with a new dockerized service that will have a three layer structure, testing, handles things in an abstract and generic way for future proofing....<p>It&#x27;s come to a point where we have about 70 repositories (mostly just generic modules like a logger or an error handling library, but still) to manage a project that, to be honest, it&#x27;s way too simple for the amount of code we maintain.<p>We all agree that we&#x27;ve fallen for overengineering, but merely being aware of this fact hasn&#x27;t made us any more effective at tackling the problem.<p>Do you guys have any suggestion about how we could both mitigate future overengineering and reducing the current codebase to acceptable levels? Anything from methodologies to rules of thumb or recommendations of books would be welcome at this point.