Wednesday, September 16, 2015

Professor Strunk's 1919 advice to developers in 2016

Before computers existed, English professor William Strunk gave sage advice on how to develop software.
"Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts."
Frankly, it was the "...and a machine no unnecessary parts," I thought especially relevant.

While preparing for a presentation at Dreamforce 15 I was reminded of this advice while considering a slide recommending Salesforce developers clean-up their change sets and deployments before moving them into production.

Honestly, during the development of even a single method or subroutine it's possible for there to be code that may have had meaning in the method's early development, but after multiple iterations has been orphaned or otherwise has no impact.  It is the developer's responsibility to identify and eliminate unnecessary code and unused variables, just as in a class unused methods should be eliminated (no matter our affection for them).  Why would it be such a surprise that unused classes, pages, components, reports, report folders, flows, images, etc. shouldn't also be eliminated before being immortalized in a production system?

"...and a machine no unnecessary parts."

Some integrated development environments (IDEs) have code browsers that are able to identify unreachable code.  I'm not yet aware of one for Salesforce development, but if you know of one please share it.

Until then, it is the developer's responsibility to eliminate code and other artifacts from their projects and repositories--remembering to pay as much attention to their static resources, permission sets, profiles, and other configuration elements as to Visualforce and Apex.

Salesforce haystacks are large enough without the code and components that do nothing getting in the way of maintenance, documentation, code coverage, and ultimately process improvement.

No comments:

Post a Comment

Follow @TomGagne