TABLE OF CONTENTS

• Introduction
• What IDE can offer regarding "conflict resolutions"
• What NOT to do as a planner (using IDE)
• Summary from ChatGPTs access to best planning principles

Introduction

There main point of this article can be summarized with a brief (and absurd!) story:

Let's say you have a restaurant and serve a dish consisting of grilled bass and call it "Grilled Bass" in the menu - then all is good, and everything is just fine...!

But if you were to change the name the next week to "Raw Shark" (while still serving grilled bass) - it would cause confusion, as the same thing is suddenly referred to as something different from the previously established name.

...Or if you after a year were to remove "Grilled Bass" from the menu and then a week later have a new dish called "Grilled Bass", but this time consisting of only carrots - it would cause even more confusion, as a new thing is being called by a previously established name.

The point here is: The moment you give something a name, there is an implicit expectation that this will stay intact for its entire lifecycle, and changing it will necessarily create confusion.

For the planner: The Activity Id (Code) is used in reporting and lifecycle tracking (in IDE and possibly other downstream systems) and changes to it should only happen under very controlled circumstances. 

What IDE can offer regarding "conflict resolutions"

IDE can to some degree handle "Grilled Bass" being changed to "Raw Shark" (the receiving schedule will have the activity renamed), but the deleting of "Grilled Bass" and then creating a new dish called "Grilled Bass" is very problematic for any downstream systems, including IDE.

However, IDE will do its best to list any such anomalies to the uploader, and will let this person decide if the new "Grilled Bass" is in fact the same as the old one, or if it is a different dish altogether that just happens to have the same name as something previously served....

What NOT to do as a planner (using IDE)

1. Be quite cautious about changing the Activity Id (Code) - it will be handled by IDE, but can and probably will cause confusion in any downstream reporting.
2. The big "No No": Do NOT delete an activity and create a new one with the same Activity Id as the one deleted. This will cause confusion as it is unclear if the newly created activity should be interpreted as the old one with the same Id (accidental delete) or if it is genuinely a new activity that happens to have the same name as a previously transferred activity. IDE will do its best to assist in resolving these issues, but this will in 99% of the cases cause trouble in downstream reporting.
3. Do not rename an existing Activity Id (Code) to the same as a previously deleted (but at some point in the past transferred) one (for the same reason as (2) above.

Summary from ChatGPT's access to best planning principles

Changing Activity Ids violates the principle of stable keys and poses a risk of loss of history and errors in integrations with timekeeping, finance and reporting. Changes should be limited to description and metadata – not the code itself.