Resource constraints as a bound to complexity

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

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

Op Tue, 20 Jun 2017 07:34:16 +0200 schreef Don Y :

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/

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

Hi Don,

This is more about psychology than system design.

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

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/

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

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

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?