Economic Design

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Economic Design

Juan Vuletich-4
Hi Folks,

When I was a kid, my father worked for a company that is generally
regarded as a world leader in the automobile market: Mercedes Benz. I
remember in the early 80's, an ad for a Basic compiler with advanced
structured stuff from Pascal. The ad presented it as "the Mercedes of
Basics". These guys were so serious when it comes to product quality,
that comparing anything with them was synonym with "top quality". I
still read from time to time old stuff from them, because I find their
attitude inspiring.

Today I found an article in a 1974 issue of an internal magazine for the
sales organization. It is called "Economic Design", and I was astonished
by how directly the ideas apply to our field. Here it is, sightly
abridged and translated from Spanish into English (my comments follow
afterwards). I hope you enjoy it as much as I do.

-----------------------------------
Economic Design
(Mercedes Benz "Información de Venta", VII./VIII. 1974/2 A/II/031)

Criteria from our development department on a hot topic, equally
interesting to both customers and salesmen.

The "economic design" subject plays a big part in our house. On one hand
we must design for economic manufacture, so we can sell at good prices.
On the other hand, we must reduce as much as possible the maintenance
and repair costs for our customers. Unfortunately, these objectives
might contradict each other, so we need to find a balance between them.

In early design phases we already try to have a small set of different
groups and elements (for example, engines, transmissions, suspension
parts) be enough for many different car models and types. We solve this
by applying a system of interchangeable elements for the whole series.
In this way it is possible to use big quantities of each group or part.
This reduces manufacture cost of each one, and also simplifies the
storage and logistics of spare parts.

These groups and their elements are subject of intensive tests both in
the test bench and in the real world. In this way we can guarantee the
required robustness and service life, while saving unnecessary expense
in materials and machining. Value analysis is done to try to make even
cheaper parts. Here, the crucial part is to state what stress can be
demanded on each part. Exaggerated demands are always bad! From all
this, we determine what expense in materials and machining are really
required to meet the requirements in the simplest possible way. Costs
and benefits must relate in a reasonable way.

But for car owners, not only purchase price is important. Later expenses
are important too. Besides consumption of fuel, lubricants and tires,
maintenance and repair costs impact considerably on profitability.
Because of this, we try to design a maximum number of parts without
maintenance, or at least, that seldom require it. Repairs must also be
possible in the simplest way.

Later, when the product is manufactured in series, a statistics of
warranty failures and voluntary repairs tells which parts fail the most.
These are subject of rigorous examination, to quickly take action, for
example, by adjusting manufacture process or part design. These
corrections are then applied to the serial manufacture.

Design also impacts on repair costs after an accident. As the front-side
collision is the most common kind of accident, all Mercedes Benz cars
have the front fenders held with screws, not soldered, so they are easy
to replace. Even soldered parts are designed to be easy to be partially
replaced. The relevant procedures have been described in Mercedes
workshop manuals since 1962.

In short, the Daimler Benz house is doing big efforts to make design
help reduce costs. Current world economics will require these efforts to
be intensified in the future.
-----------------------------

I think this text is a great lesson on software design.

It agrees with Dan Ingalls' wonderful "Design Principles Behind
Smalltalk"
http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html .
Dan says "Good Design: A system should be built with a minimum set of
unchangeable parts; those parts should be as general as possible; and
all parts of the system should be held in a uniform framework. "

The Mercedes article also sheds new light on why simplicity in design is
of paramount importance: It allows us to ship stuff that is better
tested and more robust. It makes for a system that breaks less often and
is easier to repair.

It also states that exaggerated requirements go against quality, by
raising costs for no reason. Do "the simplest thing that could possibly
work". "Make everything as simple as possible, but not simpler". In
short, it reduces both short-term and long-term costs.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Economic Design

Phil B
Juan,

On Jun 5, 2012, at 8:26 AM, Juan Vuletich wrote:

>
> I think this text is a great lesson on software design.
>
> It agrees with Dan Ingalls' wonderful "Design Principles Behind Smalltalk" http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html . Dan says "Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework. "
>
> The Mercedes article also sheds new light on why simplicity in design is of paramount importance: It allows us to ship stuff that is better tested and more robust. It makes for a system that breaks less often and is easier to repair.
>
> It also states that exaggerated requirements go against quality, by raising costs for no reason. Do "the simplest thing that could possibly work". "Make everything as simple as possible, but not simpler". In short, it reduces both short-term and long-term costs.
>

It's interesting how relatively few organizations and projects take a similar approach to the article and instead seem to become slaves to the cruft (from all perspectives whether product, service, or process) that builds up over time.  I think it's because it's easier for most people just to keep on doing what they've been doing before and tacking on whatever the new 'thing' is on top of it (in corporations that's a pretty safe way to make sure you don't get fired.)  On the other hand, I think what you've been doing with Cuis aligns with the philosophy described in the article quite nicely.

Thanks,
Phil


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Economic Design

David Graham
In reply to this post by Juan Vuletich-4
On 6/5/12 7:26 AM, Juan Vuletich wrote:

> Hi Folks,
>
> When I was a kid, my father worked for a company that is generally
> regarded as a world leader in the automobile market: Mercedes Benz. I
> remember in the early 80's, an ad for a Basic compiler with advanced
> structured stuff from Pascal. The ad presented it as "the Mercedes of
> Basics". These guys were so serious when it comes to product quality,
> that comparing anything with them was synonym with "top quality". I
> still read from time to time old stuff from them, because I find their
> attitude inspiring.
>
> Today I found an article in a 1974 issue of an internal magazine for
> the sales organization. It is called "Economic Design", and I was
> astonished by how directly the ideas apply to our field. Here it is,
> sightly abridged and translated from Spanish into English (my comments
> follow afterwards). I hope you enjoy it as much as I do.
>
> -----------------------------------
> Economic Design
> (Mercedes Benz "Información de Venta", VII./VIII. 1974/2 A/II/031)
>
> Criteria from our development department on a hot topic, equally
> interesting to both customers and salesmen.
>
> The "economic design" subject plays a big part in our house. On one
> hand we must design for economic manufacture, so we can sell at good
> prices. On the other hand, we must reduce as much as possible the
> maintenance and repair costs for our customers. Unfortunately, these
> objectives might contradict each other, so we need to find a balance
> between them.
>
> In early design phases we already try to have a small set of different
> groups and elements (for example, engines, transmissions, suspension
> parts) be enough for many different car models and types. We solve
> this by applying a system of interchangeable elements for the whole
> series. In this way it is possible to use big quantities of each group
> or part. This reduces manufacture cost of each one, and also
> simplifies the storage and logistics of spare parts.
An interesting anecdote, is that around this time, the largest US
automakers chassis/engine/transmission combinations approached 100
iterations.

On the topic of design, has anyone else on the list read "The Design of
Everyday Things" by Donald Norman?  I read it a few years ago and still
think about it every time I use a poorly designed door handle. :)


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Economic Design

Casey Ransberger-2
In reply to this post by Juan Vuletich-4
This is a great read. It's always nice to identify places wherein "software engineering" actually *does* parallel real engineering (usually not the case in my view.)

Anecdotal, but fun: dad is a musician, but my grandfather (in between fighting wars to keep the world safe for nerds like me) worked as a railroad engineer. He was one of the first engineers to use the first computer they had at Penn Station.

It didn't come with a manual;)

He won't tell me anything about the wars, but he did tell me about the computer he used stateside. It was probably part of why I ended up making software.

--Casey

On Jun 5, 2012, at 5:26 AM, Juan Vuletich <[hidden email]> wrote:

> Hi Folks,
>
> When I was a kid, my father worked for a company that is generally regarded as a world leader in the automobile market: Mercedes Benz. I remember in the early 80's, an ad for a Basic compiler with advanced structured stuff from Pascal. The ad presented it as "the Mercedes of Basics". These guys were so serious when it comes to product quality, that comparing anything with them was synonym with "top quality". I still read from time to time old stuff from them, because I find their attitude inspiring.
>
> Today I found an article in a 1974 issue of an internal magazine for the sales organization. It is called "Economic Design", and I was astonished by how directly the ideas apply to our field. Here it is, sightly abridged and translated from Spanish into English (my comments follow afterwards). I hope you enjoy it as much as I do.
>
> -----------------------------------
> Economic Design
> (Mercedes Benz "Información de Venta", VII./VIII. 1974/2 A/II/031)
>
> Criteria from our development department on a hot topic, equally interesting to both customers and salesmen.
>
> The "economic design" subject plays a big part in our house. On one hand we must design for economic manufacture, so we can sell at good prices. On the other hand, we must reduce as much as possible the maintenance and repair costs for our customers. Unfortunately, these objectives might contradict each other, so we need to find a balance between them.
>
> In early design phases we already try to have a small set of different groups and elements (for example, engines, transmissions, suspension parts) be enough for many different car models and types. We solve this by applying a system of interchangeable elements for the whole series. In this way it is possible to use big quantities of each group or part. This reduces manufacture cost of each one, and also simplifies the storage and logistics of spare parts.
>
> These groups and their elements are subject of intensive tests both in the test bench and in the real world. In this way we can guarantee the required robustness and service life, while saving unnecessary expense in materials and machining. Value analysis is done to try to make even cheaper parts. Here, the crucial part is to state what stress can be demanded on each part. Exaggerated demands are always bad! From all this, we determine what expense in materials and machining are really required to meet the requirements in the simplest possible way. Costs and benefits must relate in a reasonable way.
>
> But for car owners, not only purchase price is important. Later expenses are important too. Besides consumption of fuel, lubricants and tires, maintenance and repair costs impact considerably on profitability. Because of this, we try to design a maximum number of parts without maintenance, or at least, that seldom require it. Repairs must also be possible in the simplest way.
>
> Later, when the product is manufactured in series, a statistics of warranty failures and voluntary repairs tells which parts fail the most. These are subject of rigorous examination, to quickly take action, for example, by adjusting manufacture process or part design. These corrections are then applied to the serial manufacture.
>
> Design also impacts on repair costs after an accident. As the front-side collision is the most common kind of accident, all Mercedes Benz cars have the front fenders held with screws, not soldered, so they are easy to replace. Even soldered parts are designed to be easy to be partially replaced. The relevant procedures have been described in Mercedes workshop manuals since 1962.
>
> In short, the Daimler Benz house is doing big efforts to make design help reduce costs. Current world economics will require these efforts to be intensified in the future.
> -----------------------------
>
> I think this text is a great lesson on software design.
>
> It agrees with Dan Ingalls' wonderful "Design Principles Behind Smalltalk" http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html . Dan says "Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework. "
>
> The Mercedes article also sheds new light on why simplicity in design is of paramount importance: It allows us to ship stuff that is better tested and more robust. It makes for a system that breaks less often and is easier to repair.
>
> It also states that exaggerated requirements go against quality, by raising costs for no reason. Do "the simplest thing that could possibly work". "Make everything as simple as possible, but not simpler". In short, it reduces both short-term and long-term costs.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Economic Design

Casey Ransberger-2
In reply to this post by Phil B
Inline.

On Jun 5, 2012, at 11:38 PM, "Phil (list)" <[hidden email]> wrote:

> Juan,
>
> On Jun 5, 2012, at 8:26 AM, Juan Vuletich wrote:
>
>>
>> I think this text is a great lesson on software design.
>>
>> It agrees with Dan Ingalls' wonderful "Design Principles Behind Smalltalk" http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html . Dan says "Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework. "
>>
>> The Mercedes article also sheds new light on why simplicity in design is of paramount importance: It allows us to ship stuff that is better tested and more robust. It makes for a system that breaks less often and is easier to repair.
>>
>> It also states that exaggerated requirements go against quality, by raising costs for no reason. Do "the simplest thing that could possibly work". "Make everything as simple as possible, but not simpler". In short, it reduces both short-term and long-term costs.
>>
>
> It's interesting how relatively few organizations and projects take a similar approach to the article and instead seem to become slaves to the cruft (from all perspectives whether product, service, or process) that builds up over time.  I think it's because it's easier for most people just to keep on doing what they've been doing before and tacking on whatever the new 'thing' is on top of it (in corporations that's a pretty safe way to make sure you don't get fired.)  On the other hand, I think what you've been doing with Cuis aligns with the philosophy described in the article quite nicely.

FWIW, the cruft problem comes from executives making unrealistic promises about delivery time and engineers making bad work estimates. This happens in hard engineering too, but in hard engineering, class action lawsuits can happen as a result of design flaws. Human lives are often at stake too, which raises the bar for the QA/QC team.

My (somewhat sardonic) way of putting this is: When a "software architect" designs a broken system that falls over while people are using it, his team ships a hotfix. When a real architect designs a bridge that falls over while people are driving across it, people die and he doesn't work again. Period.

The exceptions tend to be in markets like aerospace or theme parks, where lives are at stake. Then software approaches real engineering.

In software, when we screw up and ship something that's broken, we usually ship a hotfix and maybe throw in a nice sorry form letter with a month of free service. Problem solved.

In software, thusly, the business constraints are different.

IMHO, because we are volunteers without deadlines, we can raise the bar as far as we like; in Cuis, we want to set that bar as high as we can reach. We want to have to jump in order to touch it.

But, perhaps paradoxically, we also want to ship often, and we can respond to defects with the same speed we experience in any (good) software engineering organization.

In short: Cuis gives us the best of both worlds. Just my two pence.

--Casey

> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Economic Design

Juan Vuletich-4
In reply to this post by Casey Ransberger-2
Casey Ransberger wrote:
> This is a great read. It's always nice to identify places wherein "software engineering" actually *does* parallel real engineering (usually not the case in my view.)
>  
Yes! You're right! That's one of the reasons why I liked it so much.

> Anecdotal, but fun: dad is a musician, but my grandfather (in between fighting wars to keep the world safe for nerds like me) worked as a railroad engineer. He was one of the first engineers to use the first computer they had at Penn Station.
>
> It didn't come with a manual;)
>
> He won't tell me anything about the wars, but he did tell me about the computer he used stateside. It was probably part of why I ended up making software.
>
> --Casey
>  

:)

Cheers,
Juan Vuletich

> On Jun 5, 2012, at 5:26 AM, Juan Vuletich <[hidden email]> wrote:
>
>  
>> Hi Folks,
>>
>> When I was a kid, my father worked for a company that is generally regarded as a world leader in the automobile market: Mercedes Benz. I remember in the early 80's, an ad for a Basic compiler with advanced structured stuff from Pascal. The ad presented it as "the Mercedes of Basics". These guys were so serious when it comes to product quality, that comparing anything with them was synonym with "top quality". I still read from time to time old stuff from them, because I find their attitude inspiring.
>>
>> Today I found an article in a 1974 issue of an internal magazine for the sales organization. It is called "Economic Design", and I was astonished by how directly the ideas apply to our field. Here it is, sightly abridged and translated from Spanish into English (my comments follow afterwards). I hope you enjoy it as much as I do.
>>
>> -----------------------------------
>> Economic Design
>> (Mercedes Benz "Información de Venta", VII./VIII. 1974/2 A/II/031)
>>
>> Criteria from our development department on a hot topic, equally interesting to both customers and salesmen.
>>
>> The "economic design" subject plays a big part in our house. On one hand we must design for economic manufacture, so we can sell at good prices. On the other hand, we must reduce as much as possible the maintenance and repair costs for our customers. Unfortunately, these objectives might contradict each other, so we need to find a balance between them.
>>
>> In early design phases we already try to have a small set of different groups and elements (for example, engines, transmissions, suspension parts) be enough for many different car models and types. We solve this by applying a system of interchangeable elements for the whole series. In this way it is possible to use big quantities of each group or part. This reduces manufacture cost of each one, and also simplifies the storage and logistics of spare parts.
>>
>> These groups and their elements are subject of intensive tests both in the test bench and in the real world. In this way we can guarantee the required robustness and service life, while saving unnecessary expense in materials and machining. Value analysis is done to try to make even cheaper parts. Here, the crucial part is to state what stress can be demanded on each part. Exaggerated demands are always bad! From all this, we determine what expense in materials and machining are really required to meet the requirements in the simplest possible way. Costs and benefits must relate in a reasonable way.
>>
>> But for car owners, not only purchase price is important. Later expenses are important too. Besides consumption of fuel, lubricants and tires, maintenance and repair costs impact considerably on profitability. Because of this, we try to design a maximum number of parts without maintenance, or at least, that seldom require it. Repairs must also be possible in the simplest way.
>>
>> Later, when the product is manufactured in series, a statistics of warranty failures and voluntary repairs tells which parts fail the most. These are subject of rigorous examination, to quickly take action, for example, by adjusting manufacture process or part design. These corrections are then applied to the serial manufacture.
>>
>> Design also impacts on repair costs after an accident. As the front-side collision is the most common kind of accident, all Mercedes Benz cars have the front fenders held with screws, not soldered, so they are easy to replace. Even soldered parts are designed to be easy to be partially replaced. The relevant procedures have been described in Mercedes workshop manuals since 1962.
>>
>> In short, the Daimler Benz house is doing big efforts to make design help reduce costs. Current world economics will require these efforts to be intensified in the future.
>> -----------------------------
>>
>> I think this text is a great lesson on software design.
>>
>> It agrees with Dan Ingalls' wonderful "Design Principles Behind Smalltalk" http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html . Dan says "Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework. "
>>
>> The Mercedes article also sheds new light on why simplicity in design is of paramount importance: It allows us to ship stuff that is better tested and more robust. It makes for a system that breaks less often and is easier to repair.
>>
>> It also states that exaggerated requirements go against quality, by raising costs for no reason. Do "the simplest thing that could possibly work". "Make everything as simple as possible, but not simpler". In short, it reduces both short-term and long-term costs.
>>
>> Cheers,
>> Juan Vuletich
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>    
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> -----
> Se certificó que el correo no contiene virus.
> Comprobada por AVG - www.avg.es
> Versión: 2012.0.1913 / Base de datos de virus: 2433/5054 - Fecha de la versión: 07/06/2012
>  


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Economic Design

Juan Vuletich-4
In reply to this post by Casey Ransberger-2
Casey Ransberger wrote:
> ...
> IMHO, because we are volunteers without deadlines, we can raise the bar as far as we like; in Cuis, we want to set that bar as high as we can reach. We want to have to jump in order to touch it.
>  

Hey, I like that. We'd add that to the Cuis web page.

> But, perhaps paradoxically, we also want to ship often, and we can respond to defects with the same speed we experience in any (good) software engineering organization.
>
> In short: Cuis gives us the best of both worlds. Just my two pence.
>
> --Casey
>  

Thanks, Casey.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org