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?

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/

Hi Boudewijn,

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

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!  :> )

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

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.


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

On 6/20/2017 1:04 AM, Reinhardt Behm wrote:
> AT Tuesday 20 June 2017 13:34, Don Y 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?
>
> Since most of my projects are in a very regulated market (avionics), it is
> easy to keep featurism at bay. Making something more complex than required
> will dramatically increase the certification effort and therefore cost and
> time to market. This keeps the marketing people under control.
>
> And when it is installed:
> Me: And of course we can put a bigger storage system into the unit. The cost
> for this is ...(moderate), but this will be a new certification, that will
> cost ... and take ... months. And for you this is a new component in your
> aircraft, That change to the aircraft will also need a change in the
> certification. Costs ..., time ..., the installation will ground our A/C for
> ... days.
>
> Customer: "May be we will not need this." ;-)
>
> My experience in this and other fields is just tell your customer, which
> might be the marketing guy, a high price and other effort. He might complain
> but will also "loose interest" in his great new feature idea.

I'm looking for (semi-artificial) means of constraining the design
as the resource limitations don't really exist.

Regulated industries (pharma, gaming, etc.) and/or "controlled markets"
(e.g., iPhone) effectively impose this sort of artificial constraint
(which, in theory, is based on "sound reasoning/marketing") but require
the presence of an enforcement authority.

E.g., if I don't allow "unsigned binaries" to be installed, then I've
imposed some enforcement mechanism -- but only by the presence of having
an enforcement *authority* on hand.

[Another approach is to simply lock down the system and not allow
*any* change]
impose such

AT Tuesday 20 June 2017 13:34, Don Y 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?

Since most of my projects are in a very regulated market (avionics), it is 
easy to keep featurism at bay. Making something more complex than required 
will dramatically increase the certification effort and therefore cost and 
time to market. This keeps the marketing people under control.

And when it is installed:
Me: And of course we can put a bigger storage system into the unit. The cost 
for this is ...(moderate), but this will be a new certification, that will 
cost ... and take ... months. And for you this is a new component in your 
aircraft, That change to the aircraft will also need a change in the 
certification. Costs ..., time ..., the installation will ground our A/C for 
... days.

Customer: "May be we will not need this." ;-)

My experience in this and other fields is just tell your customer, which 
might be the marketing guy, a high price and other effort. He might complain 
but will also "loose interest" in his great new feature idea.

-- 
Reinhardt

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?