TUSW Philosophy
When I first started working on SugarCRM I spent a lot of time digging the code, trying to understand how Sugar’s guys coded their standard stuffs and how I could insert my custom code, to satisfy my Customer’s requirements.
I discovered a lot of entry-points for custom code, that would let me create almost any kind of custom procedure without changing the core code : amazing ! Doing customizations without modifications at the core means don’t have to worry about core upgrades… I had just discovered the Upgrade-Safe way to do customizations.
For my personal use I’ve coined the acronym TUSW (The Upgrade Safe Way) to always remember (to myself and to my colleagues) the Rule #1 that all of us should (must) apply to SugarCRM customizations. Think of it like a stamp we put on our analysis.
Since then, I always worked in that way (TUSW) avoiding any (unnecessary) change to the core. But what when there’s no way to do customizations in this way ?!?!?!
Core changes are definitely a bad habit that throw developers in the “patches hell” (definition stolen from MS world, when we were dealing with the sadly well known “DLL Hell”) : whenever SugarCRM publish a new patch/upgrade, developers must check it for changes possibly involving the same (core) files they modified. No way, it’s too BAD !.
So I started opening bugs and feature requests (at SugarCRM’s Bug Tracker), suggesting SugarCRM people new ways to open up their procedures to customization. At the beginning I was only “suggesting”, while today I’m actively cooperating in development (through the gitHub repository open to all the Community Members or the gitHub repository open to Partners).
Knowing that in a future patch I’ll get the desired functionality, I can implement it immediately (even in a previous release, if the fix is not too heavy), quickly solving the customer’s need, with no risk for my customization.
