Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27001

Re: Resource constraints as a bound to complexity

Show all headers | View raw

Hi Boudewijn,

On 7/5/2017 8:08 AM, Boudewijn Dijkstra wrote:

>>>> Most of my designs have been ultimately constrained by the
>>>> resources available *in* the design (which, in turn, is usually
>>>> dictated by price, power and/or size constraints).
>>>>
>>>> I've been discussing this with colleagues who have invariably
>>>> had similar experiences.  None of us could "upgrade" a product
>>>> after release.  You might change the feature set or fix bugs
>>>> but the complexity of the product is effectively limited by the
>>>> design that is first "sold".
>>>>
>>>> This differs from things like the desktop market or even high-end
>>>> commerce/industry (e.g., where you could install a larger disk,
>>>> faster processor, additional peripherals, etc).
>>>>
>>>> A pleasant consequence of this constraint is that the product/system
>>>> is constrained in complexity, as well.  You don't start out with a
>>>> microwave oven and end up evolving (creeping featurism) to become
>>>> a space shuttle!
>>>>
>>>> How have folks working with more "unconstrained"/open-ended designs
>>>> addressed this problem?
>>>  There are always *some* constraints, some are hard and rational, some are 
>>> soft and impossible to quantify.  If a respected engineer thinks that 
>>> "design A" is ridiculously complex and is not comfortable with it, then it's 
>>> probably not a good idea to go ahead with it.
>>
>> But not all "systems"/designs are crafted by *an* engineer with The Whole
>> Picture in mind.
>>
>> I recall the comments of friends who dabble in the Apple/Mac world always
>> complaining that the machine they bought "isn't fast enough".  Did they
>> set out to buy a slow machine?  Was it fast and then they became "velocitized"
>> (accustomed to the speed so that it no longer *seemed* fast)?  Or, did what
>> they called on the machine to do evolve and, because there was no impediment
>> to installing more apps (and of increasing complexity), did they end up making
>> too many demands on the hardware (i.e., their *needs* changed but they were 
>> still saddled with their original purchase).
> 
> This is more about psychology than system design.

Yes.  But, if you allow a system to be extended WITHOUT REQUIRING THE
ADDITION OF RESOURCES, then the system leaves the user with a "less than
desired" feel for its performance/"value".

You get "velocitized" (acclimatized?) with exposure to a system. So,
something that seemed REALLY FAST when you bought it ends up feeling
sluggish, over time -- you become more conscious of the things that
aren't "instantaneous" (even if the system's responsibilities haven't
changed).

Allow the user to add demands on the system (without requiring the
corresponding increases in resources) and you exacerbate this problem.

[This is the "Mac hardware" scenario that I mentioned, above:  "Wow,
is this fast!" quickly turns into "Boy, is this SLOW!"]

>> By the same token, applications can become more complex in the demands
>> they place on their users without, necessarily, stressing the hardware.
>> E.g., cashiers having to type SKU numbers (from memory!) for produce
>> into their "cash registers" -- because the system expects every item to
>> have a UPC barcode (and its hard to grow apples with barcoded skins!  :> )
> 
> So you consider the user/operator and its "resources" to be part of the 
> system/design?

Of course.  A system doesn't operate without a user.   ("tree falling in woods"
scenario).

>> No doubt the developers of *individual* applications (or portions thereof)
>> don't consider *their* bits to be overly complex -- but, because they
>> are unaware of what *else* may be running on the hardware (or in the
>> "system"), can't make an informed decision as to the extent of the "total" 
>> complexity...
> 
> That's the job of the system integration engineer. If there isn't one, it's 
> probably not an embedded system.

Then your definition suggests any *extensible* system isn't "embedded"?
I.e., its capabilities must be fixed at time of deployment?

This, essentially, is the essence of the problem I've posed; how do
you prevent folks from towing a cement mixer with their little
sports car and then grumbling about how crappy the acceleration is?

Back to comp.arch.embedded | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Resource constraints as a bound to complexity Don Y <blockedofcourse@foo.invalid> - 2017-06-19 22:34 -0700
  Re: Resource constraints as a bound to complexity Reinhardt Behm <rbehm@hushmail.com> - 2017-06-20 16:04 +0800
    Re: Resource constraints as a bound to complexity Don Y <blockedofcourse@foo.invalid> - 2017-06-20 18:07 -0700
  Re: Resource constraints as a bound to complexity "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-06-22 11:17 +0200
    Re: Resource constraints as a bound to complexity Don Y <blockedofcourse@foo.invalid> - 2017-06-22 10:17 -0700
      Re: Resource constraints as a bound to complexity "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-07-05 17:08 +0200
        Re: Resource constraints as a bound to complexity Don Y <blockedofcourse@foo.invalid> - 2017-07-05 10:25 -0700

csiph-web