File length is a bit of a bike shed in my opinion. My main concern here would be separation of concerns and code quality. I prefer many short files and folders

File length is a bit of a bike shed in my opinion. My main concern here would be separation of concerns and code quality. I prefer many short files and folders structured hierarchically and grouped semantically. I have no proof this is better so I would probably just leave it to a vote with the team. In the end I think they is how a lot of this should be viewed until we get proper research. How do you WANT to code? TDD? No tests? One giant file? It should be a team and executive decision. If you don't like the style on your team, and nobody wants to change it, move on or adapt. Technical debt is like a superfund site. It renders the real estate worthless and poisons the rest of the company. It does matter. My current gig is hemorrhaging money because we can't keep devs even though the pay and benefits are great. We cannot execute on mission critical initiatives. We cannot adapt our product to meet the needs of the market in an agile way. This is due to people saying "a working product is more important blah blah.." for years. I would argue there is a balance to strike and you can do both with a good team and realistic planning. But there is always the nay-sayer who is willing to step in and say whatever product wants to hear. It is so bad we cannot train people to use the software anymore. It is too poor quality and were can't on-board them before they decide to go elsewhere. Everyone who knew anything has left and there is too much of it. So the remaining devs get overwhelmed, they leave... It is a vicious cycle. The funny thing is the money machine works, but it is so frustrating to see all of the extra money we could be making and having to leave it on the table.