I have started to read more books about software and most recently that meant reading The Pragmatic Programmer. For those who do not know it, it is a classic software engineering book that was released in 1999. In a fast moving industry, what could you possible learn from a 17+ year old technology book? Well if you read it (again) then you may be surprised. The Pragmatic Programmer is not about programming - it is about programming processes, practices, and code craftsmanship. While you may not agree with everything you find in it, some parts feel out of date, it remains overall a very worthy book. I recommend it.

Something that books do for me is to put names on some concepts that I acquired from first-hand experience. It has also fully explained others I have known from having heard them tossed over cubicle walls or conference room tables over the years. Terms like Reversibility, Orthogonality, and many others represent concepts that should guide any Sugar Developer who sits down to her daily work of customizing, integrating, and extending the Sugar platform.

So in the spirit of The Pragmatic Programmer, here is my take on what some of the lessons taught in the Pragmatic Programmer mean to a Sugar Developer.

For a "cliff notes" version of the Pragmatic Programmer, you can find a quick reference guides and other summaries online.

The Pragmatic Sugar Developer

This blog post will help you become a better Sugar Developer. Apologies to Andrew Hunt and David Thomas who are the authors of The Pragmatic Programmer.

Orthogonality of Sugar customizations

The Pragmatic Sugar Developer designs Sugar customizations to be as orthogonal to Sugar core code as possible. Keeping customizations independent and loosely coupled from the Sugar platform means that Sugar version upgrades will rarely introduce side effects or breakages. The reverse is also true, which means the Developer can make changes to her customizations that will not cause side effects or breakages in the Sugar platform either.

For example, overriding core Sugar code (like SugarBean.php) using the custom directory to implement a customization is decidedly non-orthogonal with respect to the Sugar platform. Any change in the core file will impact the override. However, customizations implemented using an Extension such as a Logic Hook, a custom Sidecar Dashlet, or using the REST API would be orthogonal to the Sugar platform. As Sugar platform evolves, these orthogonal customizations will be better protected from side effects.

Sugar core code and the DRY Principle

DRY stands for Don't Repeat Yourself. Every piece of knowledge should have an single, unambiguous, and authoritative representation in the system.

This means that a Pragmatic Sugar Developer will not blindly copy and paste core code into the custom directory. Developers should be calling APIs and not copying them. Core code should never be repeated under the custom directory where it will not be updated during upgrades.

Reversibility

The Pragmatic Sugar Developer knows that customers/stakeholders/management will often change their mind. This means that the Developer will ensure that design decisions are easily reversible in the future. The long term success of her project will likely depend on it.

Today, a customer is deploying on MySQL but later they might want to use Oracle instead. That custom chart was in a Sidecar Dashlet today may need to be moved into a custom layout tomorrow. Pragmatic Sugar Developers ensure that the right set of abstractions are in place to minimize the amount of rework associated with these change requests. Any required irreversible (final) decisions are postponed or delayed as long as possible.

Deconstruct user workflows to leverage concurrency

A Pragmatic Sugar Developer understands how to analyze user workflows and business processes to identify tasks that can be run independently and therefore concurrently. Implementing a giant workflow in one place can easily result in a solution that is a mess. Complex single threaded processes take a long time to run and lock up resources in the mean time like the user's UI, memory, etc.

Performance can be improved by scheduling these tasks to be run asynchronously using the Sugar Job Queue or on different web servers for horizontal scaling. Additionally, breaking down a large workflow into independent tasks allows for each of them to be implemented more simply and maintained more easily.

Use Sidecar to separate views from models

The Pragmatic Sugar Developer understands the difference between the views and models when building Sidecar user interfaces. They create Sidecar Views that focus on representing models in the UI and keeping them synchronized. Sidecar allows Developers to build more flexible and adaptable user interfaces.

A Pragmatic Sugar Developer works with the Sidecar framework and not around it in order to drop in foreign frameworks (ex. to incorporate a flavor of the week JavaScript framework) or techniques (ex. fetching Sugar data using jqXHRs instead of using Beans or BeanCollections). Using the native Sidecar framework allows you to minimize complexity and maintain cohesion with the rest of Sugar platform.

Design to Test using Sugar Test Tools

The Pragmatic Sugar Developer designs her tests before writing any code and includes that additional QA scope in project plans. The Developer also designs her code with the intention to make it easy to test.

Pragmatic Sugar Developers benefit from using Sugar Test Tools instead of needing to build new test frameworks from scratch.

Dig for requirements for customer success (and your own)

Developers know that sometimes customers and stakeholders can provide unreliable or incomplete information. So Pragmatic Sugar Developers do not gather requirements, they dig for them.

An experienced Developer knows Sugar better and has done more CRM projects than her customers. She uses her experience to ask lots of questions to test assumptions and uncover new requirements that need to be addressed. Very importantly, customers are often focused on explaining their current systems and processes - Developers should challenge their customers to improve processes and not implement sub-optimal or broken processes on a brand new system.

For example, has her customer thought about mobile use cases? Will they want e-mail notifications for certain actions and, if so, what should the e-mail templates look like? Is there customer data outside the CRM today that could be integrated so that users do not need to switch between systems? Is the right data captured in the CRM to support the customer's reporting requirements?