The thin lip of a teacup To give the building a sense of the delicacy associated with such crafts, as well as a feeling of warmth, I designed louvres from white porcelain panels, and used them to cover the outer walls. The louvres are tapered, to make their tips as fine as possible. (In fact, making tips as thin as possible is one of my key design principles: the thin lip of a teacup allows a better experience of the subtleties of tea - this is always at the forefront of my mind when I pay such close attention to edges.) Kengo Kuma, My Life as an Architect in Tokyo edges
An edge is an interface An edge is an interface between two mediums. Edges are places of varied ecology. There is hardly a sustainable traditional human settlement that is not sited on those critical junctions of two natural economies. Successful and permanent settlements have always been able to draw from the resources of at least two environments. Bill Mollison, Introduction to Permaculture As a kind of gateway edgesmedia
As a kind of gateway Historically, Japan's shrines have been built in order to worship the gods who live in the sacred mountains or seas; They don't reside in the shrine itself, but in the space beyond it. This belief that the spirits and deities exist beyond the confines of the shrine, and that the shrine itself acts not as a centre, but as a kind of gateway, is very different to the grand, imposing churches and cathedrals of Christianity. The majority of shrines are not found in the mountains or in the middle of the fields, therefore, but at the borders of mountain villages – which is to say, at what is seen as the edge of the mountains. The tori gate, marking the entrance to a shrine, indicates that there are gods on the other side of it. Kengo Kuma, My Life as an Architect in Tokyo An edge is an interfacePaths, edges, districts, nodes, landmarks religionedges
The value-destroying effect of arbitrary date pressure on code An Article by Gandalf Hudlow iism.org The mandate from above is clear, just get it done! Avoid everything that's in the way: all advice, all expertise, all discovery efforts that detract from hitting the Date™! What these organizations don't realize is that all software change can be modeled as three components: Value, Filler and Chaos. Chaos destroys Value and Filler is just functionality that nobody wants. When date pressure is applied to software projects, the work needed to remove Chaos is subtly placed on the chopping block. Work like error handling, clear logging, chaos & load testing and other quality work is quietly deferred in favor of hitting the Date™. Driving engineers to an arbitrary date is a value destroying mistake agileplanningqualitydiscovery