From 189dec9d29d47722ba0b955c5ba2d1c2cf95947f Mon Sep 17 00:00:00 2001
From: RPG Research <3338987+rpgresearch@users.noreply.github.com>
Date: Sun, 15 Jan 2023 11:32:48 -0800
Subject: [PATCH] Updated UML Guidelines (markdown)

---
 UML-Guidelines.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/UML-Guidelines.md b/UML-Guidelines.md
index ce56693..7fd5f76 100644
--- a/UML-Guidelines.md
+++ b/UML-Guidelines.md
@@ -1,6 +1,10 @@
 UML Guidelines
 
-General Flowcharts and Unified Modeling Language (UML) is used as part of the design phase of all our projects. While it has become (arguably erroneously) popular since about 2010-2015+ to regress back to code-first, design-later, this invariably leads to unscalable and unsustainable projects. The code-first approach tends to lead to 10% new features code (forward progression of the code base features and scaling), 85% debugging/fixing (trying to maintain/fix the existing code base), <5% documentation = garbage code that can't be scaled, or maintained when constantly changing developer eyeballs/brains.  The design-first approach, if correctly implemented with Object Oriented principles typically leads to 10-20% documentation, 20-50% new features coding iteration (forward progression of the code base), 20-40% debugging/iteration (trying to maintain/fix the existing code base), and is much easier to collaborate, maintain, and support over many years and many different eyeballs and brains.
+General Flowcharts and Unified Modeling Language (UML) is used as part of the design phase of all our projects.
+
+While it has become (arguably erroneously) popular since about 2010-2015+ to regress back to code-first, design-later, this invariably leads to unscalable and unsustainable projects. The code-first approach works okay for small, non-distributed projects, the "quick and dirty" code. But for more complex projects, the code-first approach invariably leads to chaos the moment you try to distribute the work across other developers. The code-first approach gives the illusion of more progress sooner, and does in the short term, but in the long run begins to bog down horribly, leadin to (at best) only being able to release code for 10% of the time toward new features and improvements code (forward progression of the code base features and scaling), 85% debugging/fixing (trying to maintain/fix the existing code base), <5% documentation. This all leads to an overall garbage codebase that can't be scaled, or maintained, especially when constantly changing developer eyeballs/brains.
+
+The design-first approach, if correctly implemented with Object Oriented principles, typically leads to much more sustainable and distributable codebase over time.  This usually means it works out to time spent around: 10-20% on documentation, 20-50% toward new features coding iteration (forward progression of the code base), 20-40% debugging/iteration (trying to maintain/fix the existing code base), and is SO much easier to collaborate, maintain, and support over many years and many different eyeballs and brains.
 
 We follow the principles of Object Oriented Design (OOD), even when not using OO languages, and design-first approach means it takes longer before we actually write working code (in the early phases), but leads to a much more sustainable, scalable, distributable, flexible, and manageable product overall.