Friday, November 17, 2017

The Eisenhower Matrix Fallacy

Road trips reveal truths and clarify ideas, at least that's what my Auntie Pat Tern insists. On a recent trip with her and cousin Tim Toady,  this came up when Tim requested a bathroom stop. What he said was, "I could use a bathroom some time soon." And as we flew past exit after exit, Auntie Pat Tern said he should let her know if it becomes urgent, otherwise she wanted to find a good spot to stop for lunch too. That got me thinking about competing interests when it comes to programming and the Fallacy of the Eisenhower Matrix.

Jastrow, J. (1899). Popular Science Monthly US public domain
Duck or Rabbit? It may depend on how long

you allow yourself to analyze the problem.
In a speech at Northwestern University, President Dwight D. Eisenhower said "I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent. "   


Prioritizing Competing Requirements

Important issues and urgent ones often compete. On our road trip, Auntie Pat Tern knew that a nice place to stop for lunch would also have a nice bathroom, that was part of her selection criteria. She also wanted to get as far as possible to her ultimate goal before the end of the day. Stopping both for lunch and for a separate bathroom pit-stop would delay her from reaching her ultimate goal. So she employed the Eisenhower statement as it was intended, to express that a thing cannot be both urgent and important.

Unfortunately, a lot of people in the business world have worked Eisenhower's statement into a matrix, which suggests that requirements can be both urgent and important.  Trying to accomplish a task as both important and urgent makes no sense. If it is important enough to need an optimal solution, then take the time to discover that optimal solution. If it is urgent enough to resolve immediately, do your best with what you have right now.

Importance means you have the time to be thoughtful and take time to discover the most optimal solution; it is the polar opposite of urgency.

As long as stopping for a bathroom break was important, it was worth waiting for the best location to stop both for food, which was also important, and for clean restrooms. But as soon as the need for a bathroom became urgent, the competing priority for food could be disregarded, at least to some extent. And with greater urgency, even the competing priority for a clean restroom might be set aside; the greatest urgency means you act now even if you have to pull off the road at that tree up ahead.

Eisenhower and Software Architecture 

For software architecture, the urgent and the important need to be kept separate because the important parts of the project should inevitably be the most stable code in the system. The least stable code is the stuff you write out of urgency, when things are likely to change, but we can't wait until we understand all the factors that cause change.

Don't believe the Eisenhower Matrix, it is a fallacy. Important and Urgent are like North and South ends of a magnet. Anything that is equally Important and Urgent lies in the middle, and that part of the magnet is neutral. The neutral zone is where we find the mindless and repetitive tasks that only become urgent when they are neglected for too long and only become important when something out of the ordinary arises.

For Tim Toady on our road trip, he appreciated waiting for a sandwich on Dutch Crunch and a clean restroom because he values good food; it's important as long as he doesn't have more urgent needs.

Sunday, November 12, 2017

Why Coders Use Interfaces

Going on a road trip with Auntie Pat Tern and cousin Tim Toady reveals a lot about them as only a road trip can. Tim was called a "whipper snapper" on more than one occasion for criticizing Auntie Pat Tern's driving. "I cannot wait for self-driving cars," he proclaimed while Auntie Pat Tern praised the freedom of the open road and the control she feels while driving a car. Which got me thinking about why interfaces are so important as part of my programming team's design decisions.

Tim Toady prefers to drive arcade games while Auntie Pat Tern craves a 64 1/2 mustang convertible. But they both drive reasonably well in the electric car they have at home and the gas guzzler we rented for our long drive. That's because the interface of gear shift, accelerator, brake, and steering wheel are universally well understood by users.

Accelerate, brake, steer, and shift.
The simplicity of a good interface.
That same interface translates inputs to a multitude of different systems from arcade games to tractor-trailer trucks. When it comes to deciding whether to accelerate or decelerate, the driver/user does not care if the vehicle is electric or gas-powered. A lot of people who drive electric cars even still say "gas pedal".

Autonomous driving vehicles use the same interface as people: shift, accelerate, brake, steer. By using the same interface, a person can take over in an emergency, or maybe just for the fun of driving.

Developers use good interfaces like this to future-proof their code. If the business rules are protected from the mechanism for inputting data thanks to a reliable interface, we can make sure the most important business rules continue to function as expected.

Sure, sometimes the interface has to change a bit with new business automations. When cars got automatic transmissions, the gear shift changed and we lost the clutch. The same happens with code, new automations require small changes to the programming interface, but the goal of an interface is to minimize the need for such changes. Ultimately, we want to put interfaces between systems to give ourselves flexibility to support new automation, like Tim Toady's self driving car, as easily as we support more manual systems, like Auntie Pat Tern's stick shift.

Wednesday, April 5, 2017

Real Business Data Returns

Auntie Pat Tern believes you can have your cake and eat it too, "Just use your resources wisely". So I wanted to see how to use my static resources more wisely in my Salesforce org. I have previously shown how to use static resources for test data. Now, I want to use that same data in developer sandboxes created from my org.  Since static resources are brought over like code to developer sandboxes, I can reference them in code I execute when I generate the sandboxes. Using the map datatype helps me keep relationships intact as well:

With this simple trick, I can preload my dev orgs with sample business data that I am using in my unit tests. Like Auntie Pat Tern promised, I can have my cake and eat it too when it comes to using realistic sample data in my tests and development orgs.

Whole Heaps of Fun

Auntie Pat Tern has noticed that questions about heap limits come up periodically. This could be a concern for developers needing to work with files and attachments in Salesforce. Luckily, those native objects aren't subject to typical heap limits. If you stick to blobs you can work with these large data objects. Don't use this knowledge to do bad things, now! Limits help us write code that performs well for our users as well as our fellow tenants in the multi-tenant environment we all know and love.

12:52:35:797 USER_DEBUG [43]|DEBUG|Heap: 57,789,821 / 6,000,000

Of course, if you test your code at limits, you can be sure of just how awesome your code is, which is another great reason to write thorough tests for all your code. You will find that if you are careful of what datatype you use and what you try to do with it the platform rewards you with heaps and heaps of fun.