[Cuis] Economic Design

[Casey Ransberger]

Inline. 

On Jun 5, 2012, at 11:38 PM, "Phil (list)" <pbpublist at gmail.com> 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
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org