Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26867
| 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> |
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
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