evaluation of boot execution time

Hi Don,

Don Y <this@is.not.me.com> wrote:
[]
>> Assume I have program A and program B, both of them accomplishing the
>> same task but written differently. A uses lots of global variables while
>> B doesn't use them.
>>
>> All statically allocated objects, like global variables, need to be
>> configured at run-time and will eat up my booting time. In what aspect
>> can A and B differ more that would have an impact on booting time?
> 
> You are essentially saying all hardware related issues are "off the
> table" and just looking at software issues?

Correct, no hardware differences are involved and/or taken into account 
since are not present in the current scenario.

> You could write A to be incredibly inefficient at *whatever* it does.
> While this sounds pedantic, it may actually *not* be!

Unfortunately 'inefficiency' is a quality difficult to measure; we all 
understand well extreme cases (as in your sscanf example) but there's 
nothing that qualify as a requirement for A and B.

For instance, if I knew what programming structure, objects, flow would 
have a direct impact on the booting time I can specify A/B numbers for 
all those elements (ex. use less than 10 global variables).

[deleted sscanf example] 
Keep in mind that I'm interested in what happens at 'booting' time, not 
when the program executes its main section. But I do see your point here.

[]
> In any case, you may want to consider policies or mechanisms that
> remove much of the "bad choices" from your implementation -- *if*
> the results are viable!  (e.g., don't allow VM if it's not likely
> to be used properly)

Worst of the worst is that we do not have any idea of what the algorithm 
to be implemented looks like, we are only providing the hardware with a 
certain computational capability. Yet, choices on the algorithm and its 
implementation may have an impact on the functionality (like too long 
booting time).

[]
> People tend to be notoriously ignorant of where time is spent in
> algorithms (e.g., the sscanf() example).  And, too often "prematurely
> optimize" -- often NEVER having obtained empirical data AND considered
> how that data would likely change "in the wild".

premature optimization is to be banned. Optimization is typically an 
effort that needs to look at the overall picture and concentrate in what 
makes sense optimizing. I've seen efforts in optimizing memory paths to 
reduce access time to external memory while the processor was spending 
98% of the time on local cache operations.

> Assumptions are the root of all errors and inefficiencies.  People
> *think* they know what is happening under the hood but, in reality,
> are just making GUESSES based on their own personal biases.  A better
> approach is to "do the math" (i.e., a calculator instead of a Quija board!)

Nice example the Ouija board, I didn't even know it was called like 
that! One of the root of all problems lies in the requirements 
specification itself. The too often seen problem is that customer 
specify a piece of incomprehensible list of requirements, we take it 'as 
is' in order to reassure them and 6 months after (or even later) we come 
up with all sorts of incoherences!

BTW we recently did use a software ('Lelie for requirements') to 
evaluate the 'soundness' of a requirement spec on which we already did a 
meticoulous review. It came out with 70% of our same remarks, spotting 
issues that are not so easy to spot for a stupid program. Unfortunately 
it costs too much for a small company like ours, but they do offer a 
'service' at a convenient rate per document [1].

> Set some criteria for your "boot time".  Something that your client/customer
> can agree to.  And, something that you can *measure* (think like a
> lawyer -- or a Test Technician!).  Make sure folks know the RELATIVE
> significance of this up front so they can factor it into their design
> methodology.

That is exactly what I wanted to propose, unfortunately we are close to 
the Critical Design Review and nobody gave a s**t about this item so 
far.

Al

[1] and no, I do not work for them or take any percentage on their 
selling.

Hi Al,

On 11/17/2014 1:39 AM, alb wrote:

>> Assumptions are the root of all errors and inefficiencies.  People
>> *think* they know what is happening under the hood but, in reality,
>> are just making GUESSES based on their own personal biases.  A better
>> approach is to "do the math" (i.e., a calculator instead of a Quija board!)
>
> Nice example the Ouija board, I didn't even know it was called like
> that! One of the root of all problems lies in the requirements
> specification itself. The too often seen problem is that customer
> specify a piece of incomprehensible list of requirements, we take it 'as
> is' in order to reassure them and 6 months after (or even later) we come
> up with all sorts of incoherences!

I have a standard way of dealing with "hand-waving" clients:  everything is
on a time-and-materials basis.  And, I am overly blunt in explaining it to
them as, "That way, *you* pay for the flexibility to change your mind".

When they think about this for a while, (especially after the first time they
"change their mind") they decide they don't really WANT this freedom and
want to explore other contract options.

"Fixed cost?  SURE!  That sounds great!"
"OK, we just have to decide what you *want* before I can give you a quote."
"Sure, no problem"

Then, you start asking questions to draw out the specifics of the design
(that they OBVIOUSLY haven't completely "thought through").  It won't be
more than a few minutes before they reply to one of your interrogatives with
"I don't care".  Without batting an eye or lifting my gaze from the notepad
where I've been recording their answers, I say, "When XYZ happens, the device
can catch fire and burn to a cinder..."

Of course, this gets there attention:
   "What???!  That's not acceptable!"
Putting down my notepad, I look at them, straight faced, and say,
   "But you said that you 'didn't care'?"
   "Well, I sure as hell don't want it to catch FIRE!"
   "Ah, so you *do* care!"
   <grumble>
   "So, what would you *like* it to do in that case?"
   "Well, I don't *know*..."
   "Ah, but you see I have to know what freedoms I will have in the
   design before I can give you a FIRM ESTIMATE of what it will cost
   and how long it will take.  I obviously want to make as many things
   that *you* 'don't care about' take ZERO design/test time.  Catching
   fire, turning itself off, making a loud noise or any other SIMPLE
   thing makes my life easier and the effort more predictable..."

People usually don't know what they want.  They want YOU to come up with
something -- and then they'll tell you what they *don't* want!  (i.e.,
what you have *done*!)