Underengineering: the low-code trap that feels like speed

Underengineering is a chronic issue in Salesforce and other no-/low-code platforms. Oh what a tangled web we weave when first we practice to weave webs (that’s how the spiders 🕷️ say it).

Same exact trap as code, Flows (Workflows, Zaps, Business Processes...) that grow organically can end up as either sprawling monoliths that look like city maps 🗺️ when zoomed out, or a tangle of smaller ones bumping into and duplicating each other.

At first, the organic growth feels like speed. A business requirement pops up and is immediately slapped into the system. The early cracks seem manageable: concepts like reusability and idempotency are learned the hard way, but usually only narrowly applied to the logic that led to late nights of troubleshooting and data clean up. Who has time for tech debt? (Who doesn't? Another post...)

But those quick additions & fixes pile up and the system starts to sag under its own weight. Everything runs slower, “simple” requirements stop being simple, and no one but the original admin dares touch certain logic 😬. When I’ve encountered these Rube Goldberg machines, unwinding the mess is often more work than reverse-engineering the original requirements and designing the architecture properly from scratch.

So don’t become enamored with that initial feeling of speed that comes from skipping architecting and best practices. The bill always comes due and it may just be a complete rebuild of the infrastructure your business runs on. After years of investment, can your business really afford that? 💸

-------------------------------

Picture courtesy of the spider in my backyard.