I worked a good amount of years in enterprise, and then one of my former colleagues hired me to help scale a company from startup to enterprise. He is a brilliant IT operations manager and I've now seen him build some of the most talented and successful IT operations teams in multiple organisations. Software development isn't his area of expertise though, but in non-tech enterprise software development usually falls under IT anyway. Long story semi-short, it sort of became my expertise.<p>The primary thing I've learned is that YAGNI is the best approach. One of the major hurdles I've seen in several organisations is that they've abstracted way too many things before they needed to do so. I don't blame them, here in Denmark, our various CS and SWE educations teach a lot of OOP and all the stuff which comes with it, which can basically be defined as Clean Code. I would like to point out that I don't think you can take a single principle form Clean Code, SOLID, DRY and so on and call it out as bad. I do think the overall philosophy is extremely flawed though. The way I see it is that Uncle Bob is absolutely correct when he dismisses everyone who fails as having misunderstood his principles. Unlike Uncle Bob I blame the principles and not the people who get them wrong, because so many people get them wrong. Anyway, I've seen people get stuck in abstraction hell to the point they couldn't deliver anything for their business on any reasonable time scale in virtually every organisation that have applied these things. Now, I do work with non-SWE and as such I can't tell you if these things work in places where 600 people work with software development. I can tell you that I have never seen them work in companies with 10-50 people in IT out of which around half are usually involved with software development.<p>I also see things like scaling issues rather different than a lot of people in our industry. To me running into scaling issues is a good thing. It means you've made it. Now this is a number that I'm pulling out of thin air, but I would wager that 95% of all software build here in Denmark never run into any sort of scaling issues. I also think a good amount of that software will never really need to be changed much once it's build. I think that you could build them on any tech stack with the worst cowboy code ever and be fine perfectly fine. I don't recommend doing it, but I also don't think you should focus much on how you engineer it since that won't matter until you've made it. To me it's better to rush ahead and get something working with Django, R&R, Node or whatever technology gets things out the door. I personally favor Go right now, but I do think Python will be easier for a lot of places. Then you can always re-engineer parts of it once you run into scaling issues, which you only will if you can continue to deliver for your business so that you don't become the obstacle. This is by far the hardest part of what I do. Teaching developers who are used to building things for how they think they will need to be in the future goes against what so many of them see as natural. Once they get on board though, and see how it means that they can deliver faster and focus their engineering efforts on bottlenecks as they arrive, I don't think many of them are going back. I don't go in expecting to rewrite all their existing code to remove abstractions. We typically do over time, usually be replacing bad parts with new parts when it makes sense. Sometimes it's faster for them to write a complete replacement from scratch than to refactor or rewrite, sometimes things can live for their lifecycle. The important thing is to get their ability to deliver value for the business in check so that this becomes a priority over software engineering. If you're thinking this will cost them down the line you're correct, but the thing is that by then they have more engineers and more resources to fix it. In most cases these companies will stagnate horrible if they don't change their focus, this is why they want people like me to begin with.<p>Another big challenge is usually ReBAC and automation of access control. This is somewhat contrary to what I've said before an area where I struggle to see why people don't engineer it into their architecture from the beginning. Since this is an area where you can't legally go very far with various hacks. It's also something which is frankly easy to do here in Microsoft land where everyone uses AD and EntraID anyway.