Resource constraints as a bound to complexity

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

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

Re: Resource constraints as a bound to complexity
AT Tuesday 20 June 2017 13:34, Don Y wrote:

Quoted text here. Click to load it

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


Re: Resource constraints as a bound to complexity
On 6/20/2017 1:04 AM, Reinhardt Behm wrote:
Quoted text here. Click to load it

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

Re: Resource constraints as a bound to complexity
Op Tue, 20 Jun 2017 07:34:16 +0200 schreef Don Y  
Quoted text here. Click to load it

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/

Re: Resource constraints as a bound to complexity
Hi Boudewijn,

On 6/22/2017 2:17 AM, Boudewijn Dijkstra wrote:
Quoted text here. Click to load 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...

Re: Resource constraints as a bound to complexity
Hi Don,

Op Thu, 22 Jun 2017 19:17:56 +0200 schreef Don Y  
Quoted text here. Click to load it

This is more about psychology than system design.

Quoted text here. Click to load it

So you consider the user/operator and its "resources" to be part of the  
system/design?

Quoted text here. Click to load it

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/

Re: Resource constraints as a bound to complexity
Hi Boudewijn,

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

Quoted text here. Click to load it

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!"]

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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?

Site Timeline