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


Groups > comp.arch.embedded > #27000

Re: Resource constraints as a bound to complexity

From "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com>
Newsgroups comp.arch.embedded
Subject Re: Resource constraints as a bound to complexity
Date 2017-07-05 17:08 +0200
Organization Indes - IDS B.V.
Message-ID <op.y2wsb1cdj0diun@thanatos.lan> (permalink)
References <oiabu0$dqi$1@dont-email.me> <op.y179e8tqj0diun@thanatos.lan> <oigtt8$oao$1@dont-email.me>

Show all headers | View raw


Hi Don,

Op Thu, 22 Jun 2017 19:17:56 +0200 schreef Don Y  
<blockedofcourse@foo.invalid>:
> On 6/22/2017 2:17 AM, Boudewijn Dijkstra wrote:
>> Op Tue, 20 Jun 2017 07:34:16 +0200 schreef Don Y  
>> <blockedofcourse@foo.invalid>:
>>> 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.

> 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?

> 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.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next 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