Sharepoint - SharePoint Dev and Prod running on same Farm

I think you should turn the question around. What would be the advantages?

Sure, less licenses, less hardware, only the requirement to patch a single farm etc.

But the real problem will be patching - What if the patch actually breaks something? Patches causes downtime as well as all the services in SharePoint are paused while the patch is being applied/installed. (If you don't have a clustered environment running SharePoint 2016).

That's lucky that we applied the patches for testing to our test/dev environment first so it did not break our production env.. wait a second!

And I can hardly see something beneficial when it come's to server side development.

Each time you are debugging a SharePoint Solution, Visual Studio deploys the solution to the farm and causes an IIS-reset. Wan't happy users? Try to have minimal downtime in your production environment and don't deploy solutions/patches during business hours.

Even testing out a custom solution or evaluate any kind of third party products in a shared production environment is a really bad idea. Anything can happen, and when the damage is done it could be massive and expensive.

Can you afford downtime for an hour? A day? A week? Do you have regular backups that are tested out?

The list goes on, but i think that this should give you an idea. The reasons for having multiple farms is to minimal the risks that could have an impact your business.

It depends on what you mean by "Dev". If Dev = environment to support testing code based, full trust solutions, then this is a disaster. If dev = environment to support admins in testing patches, restores, server level features, etc., then this is a disaster.

But, if dev = an environment for users to test out creating libraries and workflows, then this is fine. Users need sites to try out new things, aside from their production sites, and there are few benefits for having an entirely separate farm for this. For this scenario, all that might be needed is a separate site collection.

I think it's not a good choice. Problems I see:

• If you develop components that are installed in the folder LAYOUTS how to test new versions?
• How to test a services pack or hotfix before installing it in production?
• If you had to test a restore before in production how would you do it?
• IISReset, Timer service, jobs, etc ...

It seems to me that sooner or later, you will face a difficult problem solving or a dead end. I do not see it as recommendable.