Who said it best?
“If you don’t have time to do it right, when will you have time to do it over?” John Wooden
“There’s never enough time to do it right, but there’s always enough time to do it over.” John W Bergman
“I’m so busy doing what I must do that I don’t have time for what I ought to do…and I never get a chance to do what I want to do!” Every IT Person Ever… originally Robert A. Heinlein, Citizen of the Galaxy
Most of these will seem obvious. If they aren’t, you’re welcome.
Placing property files in a deployment package defeats the purpose of being able to update configuration values without a deployment.
Also be sure that your code supports immediate updates through property files using mechanisms such as a cache that checks for last update or a re-load mechanism that can be fired by the property file change.
When creating new projects and packages, either follow existing naming conventions/patterns or raise the need for a change and refactor all of them.
Should not require a mention as we all know it, but seems folks forget it frequently so this is a reminder.
Projects must have a readme that explains how to use the project.
Scripts should have usage notes at the top of the script. Preferably, the script should also do parameter validation and print out usage notes on validation failure.
If all calls can be managed to a singlet timeout value, set it using an application-server level configuration. If not, manage it on a per connection basis with a single property file external of the deployment archive (usually the EAR or WAR) containing the timeouts to allow for updates to timeouts without compilation.
Daily check-in of code is not optional for professional developers. There may be a rare circumstance where this is not the case, and such exceptions must be approved by the technical lead on the project on a daily basis.
An increment of work should seldom take longer than a day. All code that does not break the build should be checked in prior to leaving work for the day.
Code should be checked in each and every time it successfully builds and passes basic functional testing.
You should know the status of your own in-progress code at all times. If you don’t, then you cannot probably manage source control and the application is at risk for both difficult defects and issues during integration testing.
While the definition of technical debt is…
…the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. (https://en.wikipedia.org/wiki/Technical_debt)
the original cause of some tech debt is a combination of optimism and ego while following a best practice that should be expanded on. The best practice is to always keep code in source control to preserve work product in the event of hardware failure or accidental deletion (or the proverbial bus accident/lottery fortune).
The expansion this practice requires to truly be best is to use either a repository naming convention or a branch naming convention to indicate that source is the first iteration. The lack of this naming convention for initial commits leads to acceptance and defensiveness of early approaches that will often benefit from major refactoring if not complete abandonment.
Developers frequently avoid major refactoring for many reasons. In mature systems it can be a very real risk to do so and should be approached cautiously. However, the dislike of refactoring often impacts very early work where such changes can (and should) be done with ease.
Whether it is ego, optimism, laziness, deadline pressure, or a combination of any or all of the common factors, using naming conventions that make it clear that refactoring or replacement is expected will help to prevent early tech debt that will likely worsen over time.
The next level is to maintain and architecture decision log for the repository and require an entry to that log for any first iteration commits to reach a status where the code will be deployed. Reviewing these decisions periodically will help identify both intentional (assuming an exception log as well) and unintentional technical debt.
A frequent question on Trailhead for new admins and developers is how to edit the fields displayed in quick actions, global actions, and Lightning components. Most of the time these fields are managed through the Compact Layout for an object.
From there you can clone the default layout and create your own. Required fields must have a value for the action to work, though these fields can be left off if they have default values or there is a before action that sets the value.
HTH