What do we mean by consistency? I know some people are going to say: "Hey! That's Dan Flavin's act. Why in the hell is Irwin doing a Dan Flavin? Why is he suddenly so inconsistent – fluorescent one day and Cor-Ten the next?" The key to all of this is that we have to examples what we mean by consistency. And here the critical question is: "what do we use to measure consistency with?" If you measure consistency in terms of material, or gesture, then I will be found inconsistent. But, in all of the recent pieces and proposals, if you go to the actual site and look at it, you will find that the solution is absolutely consistent on the grounds within which it responds to its environment. This in turn is consistent with my development of the implications implicit in non-object art. Robert Irwin, Robert Irwin: A Conditional Art consistency
What's suitable for each unique condition What of machines and prefabrication? How do they compare? Well, the machine has its limits. We, using handcrafted methods, do things that machines cannot do. Of course, it's not fast like a machine. And in complicated areas like here, things wouldn't go the same using a machine as it would by hand. We use numerous variations of all these connecting and splicing joints. Using a machine, [the wood joints] can all be made uniform, but really, we need to consider whether that's a good thing. It's better to make each mechanism and joint by considering what's suitable for each unique condition. Akinori Abo, Kigumi House Chopped and disfigured contextmachinesconsistency
The heart of systems engineering While the client has some knowledge of his symptoms, he may not understand the real causes of them, and it is foolish to try to cure the symptoms only. Thus while the systems engineers must listen to the client, they should also try to extract from the client a deeper understanding of the phenomena. Therefore, part of the job of a systems engineer is to define, in a deeper sense, what the problem is and to pass from the symptoms to the causes. Just as there is no definite system within which the solution is to be found, and the boundaries of the problem are elastic and tend to expand with each round of solution, so too there is often no final solution, yet each cycle of input and solution is worth the effort. A solution which does not prepare for the next round with some increased insight is hardly a solution at all. I suppose the heart of systems engineering is the acceptance that there is neither a definite fixed problem nor a final solution, rather evolution is the natural state of affairs. This is, of course, not what you learn in school, where you are given definite problems which have definite solutions. Richard Hamming, The Art of Doing Science and Engineering: Learning to Learn What the problem isComplete and consistent requirements