Combinations and arrangements Everything designed has an element of arbitrariness in its form. Loewy described how groups of his designers used to go about designing a new model automobile. Different groups were given different tasks, such as the front and rear of the car, and the conceptual work began, to be cut off at some predetermined time by deadlines that were imposed at the outset. After a time, there were "piles of rough sketches," and Loewy saw the design proceed as follows: Now the important process of elimination begins. From the roughs, I select the designs that indicate germinal direction. Those that show the greatest promise are studied in detail, and these in turn are used in combination or arrangements with one another. A promising front treatment can be tried in combination with a likely side elevation sketch, etc. From this a new set of designs emerges. These are then sketched in detail. After careful analysis, they boil down to four or five. Raymond Loewy, The Evolution of Useful Things Useless work on useful things drawing
Such an unholy alliance Something was wrong, according to Raymond Loewy, who admitted that, "with few exceptions, the [competitors'] products were good." He was "disappointed and amazed at their poor physical appearance, their clumsiness, and...their design vulgarity." He found "quality and ugliness combined," and wondered about "such an unholy alliance." ...Loewy was also "shocked by the fact that most preeminent engineers, executive geniuses, and financial titans seemed to live in an aesthetic vacuum," and he believed that he could "add something to the field." But, not surprisingly, the people he approached were "rough, antagonistic, often resentful." Raymond Loewy, The Evolution of Useful Things On TasteWe might as well make them beautifulRestrained beauty aesthetics
Feature parity An Article martinfowler.com Whilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business. Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'. softwarefeaturesrepair