Oftentimes, you've found yourself implementing a feature (or set of features) that you have implemented before in another piece of software, in another company, or on another platform. Once you've implemented something a few times, you've got a pretty good idea of what it should look like the next time. You might therefore choose to implement a design similar to what you've done in the past, albeit pared-down and cleaned up thanks to hindsight and a fresh start. Starting with a design that worked well in the past may be preferable to starting with a whole new design that has only a vague chance of working even if the latter is mechanically simpler.

When you have specific implementation experience, consider doing the simplest thing that will probably work instead of the simplest thing that could possibly work. If it turns out the additional machinery is unnecessary, prune it off later.

-- BryanEdds
----
'''Patterns May Be the Simplest Thing To Work At All'''

I'm sure there has to be a pattern for this: Go and Load. This is for real time systems that perform some time-sensitive activity requiring a certain amount of setup before the activity is triggered. The idea is to do all the calculations and load all the values into place before the trigger comes to fire off the activity itself. Examples would be a pick and place system, continuous paper web printing, or any kind of continuous motion system that has intermittent operations performed on a moving target and synchronized by a marker of some sort.

This approach can be taken with a stepper motor control, where the time between steps is calculated and put into place, and only when the time-based trigger to step occurs (a timer interrupt) does the actual step get fired and the timer reset to the next step time. After the step happens then the positioning system can leisurely calculate the time to the next step after that and have that value put into a convenient place.

I was made aware of the pattern nature of this approach about 11 years ago when working on an industrial thermal transfer printer project. The printer used a marker on the printing substrate (food wrapping foil) to initiate an image print. From then on the positioning subsystem provided ticks corresponding to where the next line of pixels needed to be placed on the substrate.

The original software team made some serious mistakes. Sadly, the trigger tick started the (sync serial) loading of the next line of pixels into the print head, then the transfer of the image on to the film. Of course the system was pathetically slow and incapable of meeting the performance requirements of the product. I came up with the scheme of "Print and Load," whereby the next line of pixel data was already loaded into the print head and awaiting a sync tick to do the actual printing.

After the printer job I realized that this approach (which I had used even before that, again without conscious thought of a pattern) was a sort of universal solution to eliminating latency in real time systems of any kind. Therefore, I presume there is a pattern for this. Just haven't found it yet.

-- MartySchrader

''Isn't this pattern called PipeLining? -- JoshuaHudson''

'''Hmm.''' Whether or not that name is applied universally to the problem, the approach is certainly correct. Pipelining is assuming you already know the next piece of work that your operative needs to work on and getting it ready. Then, when it's time for the operation to proceed, you already have the work lined up and the operative wastes no time getting more work in place. Good catch, Joshua.

What you are doing is EagerEvaluation, calculate what you know you need or are likely to need when you know you will need it.  It's a common mechanism for achieving a responsive system for real-time systems or otherwise. -- NickPatrick
-------
Planner view countpoints: XpIsForBadPlanners
----
CategoryPattern