I'm a software developer and the codebase I work with is horrible. It is the result of no documentation and a high turn around of developers. The one constant is one of the leads, who seems to like making whimsical decisions without thinking about the long term effect on maintainability. The entire structure of the codebase and how files are organised is the result of subjective whim, and in my view is one of the reasons for the codebase being so terrible.
We have got to the point where we are looking at rebuilding the codebase (or at least small parts of it). Much to my dismay I hear this same lead sharing her same old ideas that in my opinion led to the demise of the codebase, when I know from my research that more established patterns and guides already exist that would be more maintainable and scalable.
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects? At the end of the day, our business requirements are no so unique that they require us to pioneer new conventions.
Some of the decisions have no obvious alternatives as they are unestablished concepts, for example he will decide we should have a "header-footer" folder in our UI component library (which would contain just the header and footer components) and will have some contrived reason for doing so, when really there is no established convention anywhere dictating we should do this, which would at least give me more context and confidence. For this particular example, my suggestion would be to not have a specific "header-footer" folder, and allow the header and footer components to sit along side the other components, but I digress.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?