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


Groups > comp.arch.embedded > #26867

Re: Resource constraints as a bound to complexity

From Reinhardt Behm <rbehm@hushmail.com>
Newsgroups comp.arch.embedded
Subject Re: Resource constraints as a bound to complexity
Date 2017-06-20 16:04 +0800
Organization A noiseless patient Spider
Message-ID <oiaknu$5nr$1@dont-email.me> (permalink)
References <oiabu0$dqi$1@dont-email.me>

Show all headers | View raw


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

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