We've all done it. Duplicated a set of items or a project in the name of expediency. However, it's almost never worth it unless you have a checklist of configurations to recheck.
Duplicating Projects
You shouldn't duplicate because you don't want to inherit any "bloatware" or issues from the previous project.
References May be Unused
Your duplicated project may not need all of the references that the previous one did. Unused references can cause performance issues and will complicate your project's dependencies. You know which references you need for the new project. Future developers won't know without some digging. Make life easier for future you and other developers. Don't have the unused references in the first place.
You Might Forget to Update the Project Assembly Name and Default Namespace
We've seen many cases where these values weren't updated. This is in the project properties. This can cause the project you copied it from to stop working due to its DLL getting overwritten. This could be a nasty exercise in debugging.
NuGet Package Manager Can Break
Your duplicated project may not need the NuGet packages that the previous project depended on. If these aren't removed, they can slow down your build. Overall, the more NuGet packages you have installed, the more there is to manage. You know which NuGet packages you need for the new project. Future developers won't know without some digging. Make life easier for future you and other developers. Don't have the unused NuGet packages in the first place.
Additionally, if the .csproj file you duplicated is malformed, one example being that the XML node isn't declared at the top of the file, this can cause NuGet Package Manager to behave unexpectedly. We've seen cases where NuGet Package Manager was unable to properly install or uninstall packages on projects which required manual editing of the .csproj files.
Duplicating Items
If you're duplicating an item, and even more so when duplicating a group of items, there's a very high chance that you'll forget to update all the fields and settings to be specific to the new functionality that you're working on.
Field Section Names
This is frequently missed since field section names are not typically used in code. They are merely glanced at by content authors. Wouldn't it be confusing for content authors if your new template had an incorrect field section name?
Help Text & Field Validations
Both are frighteningly easy to miss.
Delta Deploys and Revision IDs and Dates in Team Development for Sitecore (TDS)
If you're using TDS to manage items and deploy them to upstream environments, once again it's critical that you avoid duplicating existing items. If you're using TDS delta deploys, or even other serialization managers, it's very likely that your duplicated items will inherit the revision IDs and dates from the previous item. Your serializer will think the item was created longer ago than it actually was. Your item deployment may will fail or your app will behave unexpectedly when items are missing. Particularly if parent items aren't deployed but child items are.
TDS Sync and Deploy Settings
Your TDS synchronization and deploy settings may differ. By creating a new TDS project instead of duplicating an existing one, it forces you to be more mindful about how this should be configured for your new functionality specifically.
In Closing
Don't duplicate. Start each new bit of functionality on a clean slate. You'll be more thoughtful.
Imagine a world where the first project or set of items you create is a giant mess. This isn't unrealistic in the whirlwind of a new website project. Now imagine you build 50 features, all derived from those files or items that you duplicated. One day you discover a problem. Then you realize that everything has the same issue. The pain begins!
