What discussion platform are you using to discuss these changes? Slack, Emails, actual meetings, or is the lead simply leading this from the front?

If you don't have any evidence and concrete data to support your ideas then he will think you are making a whimsical suggestion. If you can justify your suggestions then you may also find arguments against the other one(s).

@AdrianoRepetti a decision to not do something there is no evidence for doesn't seem whimsical to me. My goal is to stop whimsical decisions being made, and disputing a whimsical decision doesn't seem whimsical at all.

@Snow communication is generally done face to face in person. Occasionally Slack.

@EdmundReed let me explain better: you (or your team or your lead) must decide how to organize source code (for example). It's not yes/no but A/B. Which one is better? Sometimes - honestly - it does not matter (think about all those holy wars about code formatting). When it matters then you have to make an informed decision but IT IS a decision:should you organize code/files in a higly hierarchical structure? Why yes? Why no? Pros and cons of each one? If you can't say WHY his decision is bad (which are the cons?!) then you're just rejecting a gut decision with another gut decision...

Don't fight a holy war, discuss about it but don't waste energy or time on this, if code base is such bad then I'm sure there are better topics to fight for. On the other hand you may have evidence (what went wrong because of this in the past?), in this case present it and be ready to discuss alternatives (but, again, carefully pick your battles). If you do not back up your assertions with data then they'll always be ignored. Everything else equal, to do it again in the same way it was is a very strong point in his favor.

I don't understand "when I know from my research" vs "Without having any concrete data". What did your research consist of if not concrete data? Very strongly stated opinions on StackOverflow?

Thanks @AdrianoRepetti. You talk a lot of sense. It can be tricky though, because sometimes I may dispute something because there is no evidence to suggest it is a good idea, and the idea did not come from anywhere other than the lead's head. In such scenarios, if I say "this seems bad because there's no evidence that it will benefit us", how can I back this up? Short of trying and failing, or trying and succeeding, there is little way to know, and I don't want to gamble with our codebase.

@DonFusili I agree this seems somewhat contradictory. I guess what I meant was, from looking at the codebase of similar large projects, and reading blog posts about architecture using the technologies we are using, no one else is doing some of the things that are being suggested, and using the header-footer folder example, no one else has done this, yet almost every project will have a header and footer. But I have no concrete data to suggest that having a "header-footer" will harm us, or won't benefit us.

@EdmundReed Alright, but your problem is that you think "no evidence that it will benefit us" is a good enough reason to not do something. Only "evidence that it will harm us" or "evidence that a different approach will benefit us more" are good enough arguments in technical discussions. If you haven't found those, you didn't do actual research no matter how much you'd insist you did. I'd write that in an answer, but your question starts from a faulty premise imo.

@EdmundReed DonFusili's previous comment is pretty to the point here! Note that "it will make things much more complicate without any visible benefit" might be a good reason to question a decision (but again...don't question everything...for your own, your team and your lead's sake)

@DonFusili Well, I tired to infer in the OP that the reason for the existing codebase's problems is likely due to these whimsical decisions rather than fully thought out planning, so I'm trying to avoid the same thing happening with the new code base. Perhaps I should be trying to argue that strictly sticking to an established guide would be better, rather than brainstorming, because we are all relatively new to the technology we are using, so brainstorming uninformed decisions and sticking to them seems plain irresponsible to me, even if I can't prove that it isn't a good idea.

@AdrianoRepetti to try and remain as impartial as possible, I may not necessarily know that what is being suggested is bad, I just know there's no way to know if it's good, so what this really boils down to is me not wanting to gamble unestablished ideas, and rather stick to things that have been shown to work. Am I wrong for wanting to play is safe and stick to established ideas/conventions?

@EdmundReed that's absolutely reasonable, if there isn't any more compelling reason then to stick to established and well-known conventions is a fairly good approach. Most obvious benefit is that you can pick any random programmer without any experience on your code base and it'll know how it works/it's organized, plus no wasted time to decide and to document these decisions.

@AdrianoRepetti thanks so much for your help.

Also, if you stick to community practices then there is a good chance to re-use existing tools to enforce those rules (think about fxcop, eslint & friends). With an even more important benefit: someone already tried them in the real world and advantages already proved to overcome their disadvantages (it's always a trade-off, after all)

@Kilisi I mean it can't be saved; it's a write-off. It's still in use, but to fix it would take probably 3-4 times the amount of time and effort to rebuild it from scratch. It's unmaintainable and riddled with disease. That's all I meant, demise wasn't the best word.

Many working code bases are like this, keep patching on patches. If you're not a decision maker then how is it your problem to fix?

@Kilisi I have large influence over the decision maker, and although I may not be held accountable for any problems, since I will be working with the codebase for some time and I have the best intentions I would like to do what I can to ensure the new codebase follows strict practices that are known to scale, as I believe it is best for the product.