had a beer with fellow Sugar devs the other day and (as you do) we got to talking about various pains we deal with as Sugar devs. I was thinking that we're probably not the only ones discussing this over beers, and thought it would be interesting to start a conversation with the community and just see which things come up, which things come up repeatedly, etc.
So, here are the rules:
- List any dev pain, small or large, that you have to deal with in Sugar. Keep it short & sweet or delve into an explanation, it's up to you.
- If you want, mention if/how you solved them internally
- Keep the number of items reasonable - ideally around 3-5
- Don't hate
Studio (and administration in general) - Don't get me wrong, it's a great tool for non-coders and makes lots of things possible, but as a developer I would really prefer to be able to do these things (new fields, layouts, etc. and other "mouse-based' customizations) from code directly. Not only is it much faster and more comfortable for me, but it opens the door to a lot of automation that can then be done - e.g. importing new fields, relationships etc. from a spreadsheet, which is often the format we get from a customer in the first place.
Also, Studio isn't easily extensible, which fundamentally limits the amount of things admins/presales/support etc. roles can do.
Reliable transfer between environments, e.g. dev to prod - An oldie but goodie. I'm sure everyone has solved this in some fashion, but getting customizations from env A to env B, reliably, repeatably, and quickly, is something that took a lot of "sweat and tears". This is compounded by the previous point, where Studio/ML customizations make this task a whole lot more difficult. It also needs to work both ways, because some customers use Studio to do their own simple customizations, which then need to be synced back to dev/stage environments. All this is doubly painful when SugarCloud gets involved.
(Pre)sales, initial implementations & admin handover - this one will be a little longer, and is related to the previous two points. (Pre)sales meetings always go better when you show up with a tailored demo. This usually involves "visual" customizations, things like creating fields, editing layouts, creating modules etc., which are done in Studio, usually by a team of admins, because developer time is "too precious" (the official way of saying "I don't want to", hehe). This often continues after winning the deal, during the analysis/initial implementation phase.
However, once developers become involved, we have two choices: either throw away all the work the admins did and start from scratch, or use what the admins did and spend lots of time tweaking the things that need to be tweaked. The key problem is that, because there is no easy developer interface to things done in Studio, I can't easily pick and chose - it's either all or nothing, and both approaches mean I have to spend time clicking in Administration.
Also, it's not uncommon for one of the sales guys to swing by before a meeting asking "for just this one programming customization" that's a slight variation on what's needed in every other demo, e.g. displaying a button on a subpanel (without it doing anything). But, because Studio isn't extensible, there's no easy way of enabling the admins to do that.
And finally, if, for whatever reason, it's decided that this particular demo is worth investing developer effort, we're faced with problem #2 above - demos are usually in the cloud.
IDE integration - this is probably one that's very specific to me personally, but I've always wished for my IDE to be Sugar-aware - things like hinting link/relationship names, field names, allowing me to search sugar metadata using "double-shift" (if you're using PHP Storm), things like that.
What about you?