If Ideas Had Shapes

A quoteblog ranging from philosophers in bathrobes to galaxy-rises

Category: Technology

Faroult and Robson – The Art of SQL (2006)

Unfortunately, snappy, exciting new techniques–or indeed revamped, dull old ones–often make us forget this important principle: keep things simple. Simpler often means faster and always means more robust. But simpler for the database doesn’t always mean simpler for the developer, and simplicity often requires more skills than complexity.

Advertisements

Faroult and Robson – The Art of SQL (2006)

At the center lies the relational theory, where mathematicians freely roam.

Faroult and Robson – The Art of SQL (2006)

A little knowledge can be a dangerous thing. Frequently, people may have read or heard about new or unusual techniques–which in some cases can indeed be quite interesting–and then they will try to fit their problem to one of these new solutions. Ordinary developers and architects often jump quickly on to such “solutions,” which often turn out to be at the root of many subsequent problems.

Faroult and Robson – The Art of SQL (2006)

Tactics are often used as a substitute for a strategic approach.

Baldwin and Clark – Design Rules, vol. 1 (2000)

Fundamentally, augmenting is a “wild card” operator: it is difficult to place a value on things yet to be invented, or to predict when and where those inventions will occur.

Baldwin and Clark – Design Rules, vol. 1 (2000)

If the downside of “bad draws” in the design effort can be controlled by rejecting bad outcomes, technical risk and complexity may be good things. The reason is that modules with more technical risk or complexity may have wider distributions of outcomes than other modules. If the downside risk can be controlled, that leaves only the “upside risk”–the possibility that the experiments will uncover very good designs (high peaks in the value landscape)

Baldwin and Clark – Design Rules, vol. 1 (2000)

One insidious aspect of first-time modularizations is that design rules flaws are revealed only very late in the process. Once the rules are in place, work on the individual modules proceeds independently and may appear, for a time, to be going very well. It is only when the pieces are brought together for final integration and testing that unforeseen interdependencies are brought to light.

Baldwin and Clark – Design Rules, vol. 1 (2000)

All the necessary design rules would be established in the first phase, which was projected to last about ninety days. (In fact it took ten months.)

IBM designing System/360

Baldwin and Clark – Design Rules, vol. 1 (2000)

However, as we said in chapter 3, to achieve true modularity in a design and corresponding task structure, the mental decomposition of the artifact is not enough. Designers must also have experience with many actual designs in order to understand precisely the nature of the underlying parameter interdependencies. Only when that knowledge is in place is it feasible to think about converting mental components into actual modules.32

32 Attempts to modularize without sufficient knowledge result in the discovery of interdependencies, which may render the system inoperable. The real design and its task structure will remain stubbornly interdependent and interconnected until the designers know all the points of interaction and can address them via sensible design rules.

Baldwin and Clark – Design Rules, vol. 1 (2000)

Despite its elegance and flexibility, the concept of microprogramming did not take the industry by storm. The greatest criticism leveled against the idea was that it was inefficient. Wilkes’s approach was more complicated and circuitous than the usual way of building machines. There was also a performance disadvantage implied by the double decoding of instructions. Finally, fast memory, which was critical to implementation of the concept, was expensive. Thus many designers believed that they could build faster machines at lower cost by hardwiring the “right” set of instructions in the first place.

These criticisms were fair but missed the essential point. When Wilkes asserted that microprogramming was the “best way” to design a computer, he did not mean it was the “highest speed” or “lowest cost” approach. What Wilkes sought above all was flexibility and ease of improvement. More than anyone else of his generation, Wilkes expected all the components of the computer to get better over time.