From time to time the question pops up: what's your software stack? I use cloud based tools like LucidChart, GitHub, Bitbucket and various other SDLC related tools (subject to a future post), but still quite a number of locally installed tools.

The essentials

Tools I use on, more or less, daily basis:

• NodeJS (unsurprisingly)
• Salesforce CLI
• Heroku CLI
• Visual Studio Code with a few plugins:
• SFDX Plugin
• PMD Plugin
• Mocha Sidebar
• Jest plugin
• Git Lens
• Prettier
• Live Share
• Tower GIT Gui (and of course GIT command line) - or SourceTree
• OpenSSL
• Eclipse - for Java development. Never warmed up to other Java IDEs (I tried)
• DiffMerge tool
• a current JVM and JDK
• The Welkin Suite - for Salesforce development
• Postman - the Swiss Army Knife for REST
• Pencil and Balsamiq for wire frames (The former when I need to share the raw file, the later when my counterpart has Balsamiq or images are sufficient)
• Sublime - Editor super fast

When you develop in Lightning your client side architecture can benefit as much as the server from a separation of concerns. The component library is testimony to that.

Out of the box services

The Component Library features a growing number of services:

• Lightning Data Service, the workhorse of creating, loading and saving Salesforce records. One specialty: it doesn't have its own component, but surfaces through force:RecordData, lightning:recordEditForm, lightning:recordViewForm and lightning:recordForm
• Overlay Library to show modals and popovers
• Notification Library to show notices and toasts
• Omni Toolkit API for accessing OmniChannel capabilities
• Navigation Item API to move around in lightning
• Conversation Toolkit API to interact with chat
• Quick Action API accessing quick actions
• Workspace API to access console app tabs and subtabs
• Utility Bar API to access the utility bar
• Emp API to subscribe to streaming events

Building your own

There is more than one way to skin you cat. You can do:

• Lightning Style
  Philippe Ozil described in detail how to use and create your own services 'lightning style'. You should check out his Server Side Actions Service that allows you cut down on boiler plate code substantially
• JavaScript Style
  Establish a global service extending the Window object
• ES6 Style
  Import a JavaScript module. This would need to setup Babel - not too practical for now

Extending the window object

When you extend the window object, which is the browser's top level object, the service becomes available "standalone", like alert() (which is actually window.alert()). A service could look like this:

window.demoLib = ( function() {
 let someMethod = () => {
  return 'Something'
 }

 let helloMethod = (paul) => {
  return `Hello ${paul}`;
 }

 return {someMethod, helloMethod};
}());

This will now provide you with demoLib.someMethod() returning Something and demoLib.helloMethod('World') returning "Hello World". The final step to enable such a library is to add ltng:require to your components: <ltng:require scripts="{!Resource.demoLib} afterScriptLoaded="someMethodIfRequired" /> presuming you stored your JS in resources as demoLib.js. The Aura framework will make sure that the library is loaded once only, regardless how many components define it as dependency.

What can go wrong?

There are a few caveats:

• For hard core Apex developers: JavaScript is case sensitive
• You need to be clearly communicating service names to other developers in your org. If someone has the idea to name a library the same as yours, things will break. Good practice is to check if your library and function is available: if (window.demoLib && window.demoLib.someMethod) {...}
• Fat arrow functions () => {...} are not supported in legacy browsers, so you need the slightly more verbose function(){...} (beware the this keyword behaves different then).

As usual YMMV

A common practise in IT, as run up to a sale or a project is to proof that the intention of the undertaking can be fulfilled.

The challenge

A PoC needs to strike a challenge between effort and coverage. A final proof of a project is its completion, so the temptation lures to try to proof everything. On the flip side: if they core functionalities aren't covered the proof has little value.

The second challenge is to define concise successs criteria. Quite often, especially for standard product PoC, it is left to 'how users like it' - which isn't a really qantifiable result.

Use cases

A workable approach is to define use cases, that cover a typical scenario, like 'Sale of an ice cream'. This scenario needs to be broken down into business steps until a step can be looked at: 'did work / did not work'.
The breakdown needs to be business level, business language. So 'Can click on customer info' should rather read 'Customer info is retrievable'.

Use cases and steps are hierarchical, typically 2-3 levels are sufficient for most PoC. Deeper levels are a smell that you are looking at a pilot or full fledged project, not a PoC.

So, in a nutshell: A PoC line item needs to have a binary answer. If a binary answer isn't possible break the line item into smaller units. Stick to the domain specific language (usually: the business steps)

Measurements

When a use case line item has a binary outcome (works / doesn't work), the simplest measure is to check if everything worked to declare the PoC a success. Usually doesn't help.

The next level is to define a pass percentage. Like 70% of 200 line items must pass. Again a simple solution. Challenge there: nice to have and essential features have equal weight. You could end with an outcome that has all nice-to-have features, but might miss essentials.

So the next level is to define weights for each items, including a showstopper flag for must-have features. Weighting discussions are popular battle grounds for feuding fractions, since the weight determines outcomes, especially for concurrent PoC execution.

Another weakness of this approach: works/doesn't work as binary value doesn't cover: 'Does it work well?'. Like 'Is a pair of sneakers suitable to get from Boston to New York?' The binary answer: Yes you can walk, but the real answer: use a car, train, bus or plane.

Balanced Scorecard to the rescue

Looking at the definition of Usability, one can find 3 criteria:

• Does it work?
• Is it efficient?
• Is the user pleased?

I would treat the first column as a binary value and the later two as scales from 1-5. This allows to generate a balanced score card that reflects important aspects of a proof. Depending on the nature of the system, you could add additional columns like 'failure resistance, error recovery, risk'.

While it doesn't relieve you from the weight bickering, it provides a clearer picture of actual outcomes.

As usual: YMMV