Salesforce.com Dreamforce 2010 Developer Track Presentation: alesforce and Force.com have a great reputation: easy to configure, fast to develop with, and marketed with an "anyone can do it" paradigm—all true. But just because something is easy and fast doesn\'t mean it should be treated in a cavalier manner. In other words, just because you can put 500 validation rules on an object doesn\'t mean you should. This session will focus on bringing best practices for enterprise systems to bear when developing on the Force.com platform. Join us to learn about using a standards-based approach to coding, data modeling, and architecting as well as separation of concerns, test-driven development, and more.

1. They Call it "Enterprise" for a Reason Developer Don Robins Outformations, Inc. www.outformations.com

2. Safe Harbor Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of intellectual property and other litigation, risks associated with possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year ended January 31, 2010. This documents and others are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements. 1

3. How Big Is The Enterprise 2

4. Which One? 3 Image credit –www.cygnus-x1.net : Monte R. Johnjulio

5. How Big Is Big? How Many of You Have… Total # of Users > 100, >500, >1k Total# of Integration Points > 1, >5, >10 Other Benchmarks… Total # of Standard + Custom Objects Total # Custom Workflows Total # of Triggers, Classes, VF Pages Total # Records 4

6. How Big Is Big? How Many of You Have… Followed in someone’s footsteps who is not available anymore? Been baffled by something you found in your org? Broken existing functionality when trying make a change? 5

7. Large scale Salesforce.com and Force.com implementations require a different approach: You need to think differently Why and How to think differently We need to amend the Marketing Message: “…it’s so easy!” Objective: Share My Perspective 6 Image credit – Apple, Inc.

8. Objective: Take Away(s) For You Perspective: (What) Size : Complexity : Dependency : Risk Understanding: (Why) You need tomanage complexity Ideas: (How) Change your approach Managing expectations differently Adopt new standards, practices and methods 7

9. Who Am I? Co-Owner & Principal Consultant of Outformations, Inc. 25+ years experience Chief Architect, Development Team Mentor and Trainer Certified Salesforce Developer & Certified Agile Scrum Master What Do We Do Custom Software Solutions Agile Business Consulting Developer mentoring and training Clients of all sizes, shapes and industries We love moving customers into the cloud w/ Force.com 8

10. What Does 'Enterprise' mean? Many Objects: users, features, screens, reports Many Complexities: security, business rules, workflow, reporting, output Many International Issues: multiple locales, currency, time-zone issues Many Integration Points: other cloud systems, ERP databases, etc. And of course - oodles and oodles of data 9 Image credit – Wenger

11. “Salesforce Development Is SO Easy!” Salesforce.com marketing message: 'easy' to configure 'rapid' to develop with 'anyone can do it' ‘No Software’ It’s all true - that's why we love it BUT – we must Amendthe Marketing Message: Applies to Salesforce Does NOT apply to complex systems 10 Image credit – Quantum360.co.uk

12. What’s The Problem With Big? Big things tend to get Complex Complexity grows in an arbitrary manner Growing Complexities create Dependencies Gets harder to track everything System elements typically become more coupled Changes have unintended impact Technical debt can grow You will have to pay: How? When? At What Cost? You can't know! 11 Image credit – OpenORB.sourceforge.net

13. What is Technical Debt? ‘...eventual consequences of slapdash software architecture and hasty software development.’ 12 Image credit – my.digitalface.ca

14. Arbitrary Changes = Technical Debt 13 Image credit – my.digitalface.ca

15. Technical Debt Scenario Someone needs and requests a ‘simple’ change You 'solve' the problem with a quick solution as expected The solution adds another moving interconnected part This happens again and again and again over time… APEX logic may become redundant You plan to ‘fix’ or ‘improve’ it later, but ‘later’ never comes! Complexity grows introducing unforeseen dependencies Changes introduce unintended impact Tests start failing when you go to promote new code Deployment and implementation changes become impeded Eventually your system implodes (‘forecloses’) on itself… 14 Image credit – my.digitalface.ca

16. Technical Debt Examples “We just need one more <fill in the blank> ‘just one more validation rule…’ ‘just one more field’ Changing Picklist values w/o verifying dependencies Making arbitrary APEX Changes Adding new triggers Bloating your classes Adding new (and potentially) redundant logic There will be implications! – So what do you do? 15 Image credit – my.digitalface.ca

17. Adopt Development Best Practices Accept Salesforce.com as Enterprise class product Supports complex systems; your system will get complex! Set expectations accordingly for everyone A cavalier approach will have implications Learn Enterprise software development practices Supports development of complex applications Been around for years and have evolved over time Allow scalability and management of growing complexity Perfectly applicable to Salesforce Applies to BOTH Configuration and Coding 16 Image credit – consulting-plus.com-au

18. Adopt Development Standards Set your standards – any good set of standards will do All team members should follow them when: Designing Data modeling Configuring Coding Enforce with all users allowed to configure! Make the risks visible and set expectations for ALL! Easier to accept when we know their purpose 17 Image credit – consulting-plus.com-au

19. Adopt Naming Conventions Establish naming patterns in Declarative Programming THINK when naming custom object and fields Caption vs. Fieldname User vs. Programmer Same for Programming Components Use naming patterns for collections of related classes Organize Triggers, Classes, Pages, Components by name Name test classes after the class that they test ex. MyPageController and MyPageController_Test Keeps them together and searchable 18 Image credit – www.squidtank.com

20. Reduce Complexity Where You Can Just because you can…doesn’t mean you should: DON‘T add hundreds of fields on an object DON‘T have dozens of validation rules on an object As you decrease… Fields, Rules, Complexity You may increase… Performance, Usability, Maintainability Understand that complexities need to be managed 19 Image credit – www.emergebuzz.com

21. Analyze Potential Dependencies Think before you click! Do analyze and vet change requests with your users Don't arbitrarily accept change requests Make sure there is clear business value Do user reviews showing available options Share understanding about dependencies and risk Provide alternate options and build prototypes Don’t give in to the argument: ‘But it should be so easy to do…it’s Salesforce!” Don’t ‘code’ when you can ‘click’… 20 Image credit – planebuzz.com

22. Leave a Trail (Declarative) Capture and Communicate Keep complexities and dependencies visible! Leverage documenting meta fields Fill in Description and Help on ALLobjects Validation Rules, Approvals and Workflow, etc. Be explicit Don’t be overly verbose 21 Image credit – www.legaljuice.com

23. Leave a Trail (APEX) Comments in APEX code inform at a glance BUT: Use comments with care Misleading if outdated Don't say ‘what’ or ‘how’… Say ‘why’ APEX code limit 22 Image credit – www.legaljuice.com

24. Leave a Trail (APEX) Use consistent naming conventions and patterns Methods, properties and variables should self document Name properties for what they contain or represent Names CAN be long 23 Image credit – www.legaljuice.com

25. Adopt an Architectural Approach Use Design Principals to help Manage Complexity: Separation of Concerns (SoC) Single Responsibility Principal (SRP) Don’t Repeat Yourself (DRY) Use Good Coding Practices for Maintainability Self Documenting Code Avoid String Literals (use constants and enums – not picklists) Regularly Refactor your methods and classes Keepclasses and methods light weight Code for ‘understandability’ not ‘terseness’ 24 Image credit – consulting-plus.com-au

26. Adopt an Architectural Approach Leverage Enterprise Coding Patterns Designed to manage complexity Provide consistent frameworks to 'know' where things go And where to find them later when needed Adopt a Modular Approach(APEX) Promote reusability : reduce redundant code Data Access Services: encapsulate SOQL and DML logic Domain Managers: encapsulate domain logic Utility Libraries: reusable functions Service Libraries: reusable services 25 Image credit – consulting-plus.com-au

27. Example: Separation of Concerns SoC is NOT just Model/View/Controller (MVC) Over arching architectural approach Create modular code components Decouple your logic whenever and wherever possible Push business logic beneath triggers and controllers Treat APEX like a first class OOP language Build test classes for each modular APEX class Makes everything more testable 26 Image credit – blogofpaul.merecomplexities.com

28. Trigger Rules Helper Logic SOQL DML Typical Architecture VisualForce Views Controller Actions Navigation Rules Helper Logic SOQL DML Trigger Tests Controller Tests 27

29. Modular Architecture VisualForce Views Trigger Trigger Tests Controller Controller Tests Service Service Tests Manager Tests Manager Repository Repository Tests Utility Utility Tests 28 Image credit – outformations.com

30. (Really) Test Your Code TRUTH or DARE: How many of you: Write your tests AFTER you've written your APEX classes? Have failed a deployment because of unexpected lack of coverage? Maintain only ONE test class for MANY APEX classes or triggers? 29 Image credit – consulting-plus.com-au

32. Code With Intent What is Test Driven Development (TDD)? Writing your tests as you code HELPS you develop your logic Leverage the concept of ‘emergent design’ TDD approach can help you 'code with intent' You must think about what you’re coding Prevent wasted effort and code bloat Robust set of tests for regression testing Provides security (and peace of mind) with change Our applications will need to be managed for many years Writing Code = 20% vs. Maintaining Code = 80% 31 Image credit – consulting-plus.com-au

33. Adopt Agile Project Management Develop and maintain a Product Backlog Highest priority/value items Work in short iterations (sprint) Tight feedback loop Commit to only what your team can complete Realistic and sustainable pace The team touches base daily with project owner Visibility of progress and impediments Perform Demo and Retrospective at end Do it again… get better…get faster…get predictable 32 Image credit – consulting-plus.com-au

34. Benefit From an Agile Approach Promotes the delivery of Business Value Forces prioritization from the business perspective Maintains visibility and raises impediments daily Identifies where the real problems are (often not the tech) Improves team performance and delivery The team gets better and faster – more predictable Insures rapid user feedback of whether you’re on track Helps manage ever-present changes Reduces un-necessary features + less waste = less cost Change is a ‘Given’ - don't fight it; embrace it. 33 Image credit – consulting-plus.com-au

35. In Summary Manage the expectations of your users and managers Let them know what they're really dealing with Learn to manage and leverage the platform Don’t let it manage you Adopt an Enterprise approach for an Enterprise platform It’s built for scalability - that's why you use it They call it Enterprise because it IS Treat it as such 34 Image credit – www.infovark.com

36. Take a Minute Please fill out the session survey. It helps us learn about how to improve this information. 35 Image credit – www.eizie.com

37. Questions? Stay after Talk at lunch Find me on Chatter (or LinkedIn) Email me at dbr@outformations.com My website http://www.outformations.com I will post follow-up links and info in Chatter Post your questions on the Chatter Feed 36 Image credit – www.clipartof.com

38. Don Robins Outformations, Inc. www.outformations.com