A Useful Winter 16 Function

Not many people will notice a small function in the winter 16 release which has potential to help the performance considerable of the entire platform, if we all use this function wisely.

System.SObject Class

recalculateFormulas()

Recalculates all formula fields on an sObject, and sets updated field values. Rather than inserting or updating objects each time you want to test changes to your formula logic, call this method and inspect your new field values. Then make further logic

changes as needed.

For example :

You want to insert an Account in a testmethod and you are wanting to test that your formulas will be calculated correctly. Previously you would have to perform a DML. And we all know how expensive DMLs are for the platform. This little formula bypasses the need to do the DML.

Say your Account is quite basic and has several formula fields.

Account acc = new Account(Name='Steves Test'); //Now test a formula field StevesFormula__c to have the "This is a test" as the value without doing a DML acc. recalculateFormulas(); system.assert(acc.StevesFormula__c == ' This is a test');

The New World Of Debugging

I cannot begin to describe how Im feeling. Im just so excited. Have you seen the new debugging capabilities in Eclipse and the Developer Console. If you havent stop what you are doing now. If you are drinking a nice bottle of Moet, or you are digging into some nice chocolate cake. Stop! Open up Salesforce and have a look.

But is this exciting, is this thrilling, well for some it isnt, but for me god damn it is. Why?

With these tools you will be able to develop faster and so release faster and so satisfy your stakeholders and keep them happy.

You can now do the following:

1.    You can run individual test methods in a test class

           

            You can now select individual test methods from your test classes to

include in a run. You can also choose whether to run tests synchronously, and you can rerun only the failed tests

Oh I was 1 of the people suggesting this many years ago on IdeasExchange

2.    If you have hit debugging levels regardless of what logging level you set, you can now start your debugging at a specific point in your code to prevent this

Trace flags now include a customizable duration. You can also reuse debug levels across trace flags and control which debug logs to generate more easily than ever before. This feature is available in both Lightning Experience and Salesforce Classic. A debug level is a set of log levels for debug log categories: Database, Workflow, Validation, and so on. A trace flag includes a debug level, a start time, an end time, and a log type. The log types are DEVELOPER_LOG, USER_DEBUG, and CLASS_TRACING. When you open the Developer Console, it sets a DEVELOPER_LOG trace flag to log your activities. USER_DEBUG trace flags cause logging of an individual user’s activities. CLASS_TRACING trace flags override logging levels for Apex classes and triggers, but don’t generate logs.

Debug > Change Log Levels

3.    Of course there are other features you should check out. Such as all the Analysis features, go to 

Debug > Switch Perspective > Analysis

You can check any limits that you may be approaching.

You can check how long it takes to run certain functions and what actions occur when during execution.

You can see the order of execution in a tree diagram and other various ways

You can trace variables as they change in your code

4.    Eclipse debugging

Use the Apex Debugger to complete the following actions.

• Set breakpoints in Apex classes and triggers.

• View variables, including sObject types, collections, and Apex System types. • View the call stack, including triggers activated by Apex Data Manipulation Language (DML), method-to-method calls, and variables.

• Interact with global classes, exceptions, and triggers from your installed managed packages. When you inspect objects that have managed types that aren’t visible to you, only global variables are displayed in the variable inspection pane.

 • Complete standard debugging actions, including step into, over, and out, and run to breakpoint.

• Output your results to the Console window.

The Importance Of Estimating Requirements

The Importance Of Estimating Requirements 

I havent been blogging for a while mainly because Ive been doing some DIY work in my house, so although my blogging and my readers have suffered my kitchen is looking much better .

In this blog Id like to talk about Estimation, something developers dont like much.

Estimating requirements and estimating accurately is more important than most developers think it is. Most think it is just another administration task that stops them developing, but without it companies struggle to operate correctly.

There are different types of estimating such as using story points http://scrummethodology.com/scrum-effort-estimation-and-story-points/. Or using estimating by time.

Personally I suggest it doesnt really matter which method you chose to estimate stories. Remember a story at this stage has the basic outline of the work and not the detail, so the estimate is a very approximate one.

But if I were to chose a method I would chose estimate by time. The reasons are, time is a universally known gauge and doesnt need to be calibrated; when new members enter your team with story points they need to be taught what your story base point is, whereas with time you dont; if you have more than 1 team in your company each team may have a different story base point and so if you move staff around teams this can be confusing for the team members and lead to inaccuracies. Another benefit of using time is that this can be used to calculate forecasted budgets much easier, whereas if you use story points you first need to translate this into its equivalent time then to work out the forecasted budgets. Of course you could argue if you are working on a set sprint length of say 2 weeks and you can complete 5 story points per person in that 2 weeks then this is the only translation into time that you need.

As it comes closer to the project development start date more finer detail of the requirements are gathered and the stories are broken down into small individual tasks.

Some teams believe they only need to refine the story points they gave at the beginning and then calculate how many stories they can fit into a sprint, based on the priority of the stories.

I agree on the overall concept of this but I believe the individual tasks should be sized themselves. The only issue here if you use story points you can a scenario where you have 0.1 story points and so this undermines the value of using story points on Tasks of the Stories.

Many teams dont bother entering their actual time spent on Tasks or Stories. Is it really required if you say you are going to deliver 15 Story points in a 2 week sprint and that is exactly what you do deliver, does it really matter if you log your actual time. Well I would argue it does.

Say for example you have 2 Stories and say you use time to size Stories, if you estimate that both Story 1 and 2 will take 1 week each to complete, but in reality Story 1 took just 2 days to complete but Story 2 took 8 days. Both Stories were still completed exactly on time that was estimated, but actually in reality the team is very bad at estimating and this should be improved.

In the next sprint the team could get it very wrong and grossly under-estimate both Stories and only deliver 1 of them.

The trade-off however is the extra administration time required to enter actual time worked.

So on balance I would suggest use time to estimate both Stories and Tasks. Start with entering Actual time until you prove the accuracy of your estimating at both the Story and Task level. Once you prove a consistently high % accuracy level across all team members you can remove the extra administration required to log actual time. Of course if new your team changes considerably you may need to restart the actual time logging for a period.