Quantcast
Subscribe!

 

Enter your email address:

Delivered by FeedBurner

 

E-mail Steve
This form does not yet contain any fields.

    free counters

    Twitter Feed
    « HR Technology - Do You Care? | Main | Self-Sufficiency »
    Tuesday
    Sep282010

    Optimistic Memory

    This morning on a radio talk show I heard a phrase for the first time - 'Optimistic Memory'.  The person was (I think) referring to having a more favorable recollection of past events than perhaps was warranted, and failing to accurately recall said events with the proper scrutiny and measurement.

    This is not unique, or particularly interesting I suppose, who hasn't fallen victim to having a kind of selective remembrance of prior events or circumstances, be they jobs, athletic 'achievements', or past romantic interests.  Heck, I even know a guy in the HR blogosphere that describes some of his past girlfriends as 'South Beach models'.  But I digress.

    But the actual phrase, 'Optimistic Memory', sounded really distinctive, as I had never heard the dull old concept described in such a manner.  Consequently, minutes of diligent research ensued (one Google search), that led me to a National Institute for Computational Sciences (I never heard of them either), page containing the following definition for 'Optimistic Memory (allocation)':

    Optimistic Memory Allocation means that Linux is willing to allocate more virtual memory than there is physical memory, based on the assumption that a program may not need to use all the memory it asks for.

    So in layman's terms, the concept of Optimistic Memory in a Linux computer system has less to do with looking backward than with looking forward. It is a kind of design that attempts to release computing resources using an 'optimistic' assessment of the need for said resources.  It says - 'Ok process ABC, you are asking for X amount of resources, and I only have 50% of what you are asking for readily available, but I will go ahead and let the process start, because I am pretty sure you really don't need all the memory you are requesting. 

    It is in a way the exact opposite of what systems folks are trained to do, and what often experience suggests when planning projects, estimating costs, and assessing risk. I am sure we have all heard the old standards of 'Take the initial estimate and double the time/resources/costs' mantra when in project scoping or solution design phases.  

    But why is that the case?  Are we (the collective we, surely I don't mean you personally), really so bad at truly understanding new technology, estimating our own skills and capability to utilize new tools, or assessing the organization's capacity to adapt and change?  Are we simply tying to cover our own flanks by making the dire error of actually underestimating the level of effort to do anything? 

    I don't know, but sometimes I think that our inability to see things positively, to actually employ some 'Optimistic Memory' in the face of change or innovation or new technologies is a handy anchor to keep us safely in port instead of actually venturing out to the open water. Better to keep the staus quo than try and fail perhaps.

    Horrible post, I know.  But it did start out optimistically, and that has to count for something.

    PrintView Printer Friendly Version

    EmailEmail Article to Friend

    References (1)

    References allow you to track sources for this article, as well as articles that were written in response to this article.

    Reader Comments (2)

    *cough Love the line about South Beach. It made my day.

    September 28, 2010 | Unregistered CommenterJohn

    I always believed the reasons for the doubling of resource estimates were 1) to account for unforeseen "management," which will slow you down, and/or 2) to provide cushion when your "estimate" becomes an "approved by the board" timeline.

    September 28, 2010 | Unregistered CommenterDwane Lay

    PostPost a New Comment

    Enter your information below to add a new comment.

    My response is on my own website »
    Author Email (optional):
    Author URL (optional):
    Post:
     
    Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>