Usually you see architectural (building) concepts influence software design. Here is a bit of the reverse:

I recently purchased a new home. The .28 acre lot is populated by a dozen tall oak trees; the house was built in 1961 and is a modest little split-level brick building. It had a kind of WabiSabi thing going.

Unfortunately, a week after moving in, I began to notice the signs of ''house abuse''. The previous owners had neglected (and even damaged) certain systems (electrical, plumbing, drywall, etc): Things that did not show up in the home inspection.

Now, consider an equivalent software system. You have inherited a functional but unwieldy code base. You want to make improvements. '''You Refactor'''.

I am now finding myself in the midst of ''Refactoring'' my home. My family has to live there and use it on a daily basis, so a re-design or re-write is not possible. In fact, totally gutting any part of the house will cripple its functionality. So, my wife and I are slowly but surely Refactoring the house. Small, incremental changes are made without sacrificing what current functionality. For example: change a faucet, but first add shut off valves under the sink; redo bathroom tiles, but first move daily routine to another bathroom. 

Obvious things. Pattern-like things.

-- ToddCoram

---------------

'''''"Me too!"'''''
-- JeffGrigg
''(Who '''just''' bought and moved into a house -- 10/28/2000)''

-----
''Moved from YouArentGonnaNeedIt''

I keep thinking about VeryCoolBuilding when I see this page updated. The architects designed a building that would top the ChryslerBuilding and become the tallest building ever (at the time). This was in the early 20s. They thought they would need the structure to support it. They had to make certain assumptions that they would be able to achieve what they designed.

But things always come up that you don't expect.

The Depression hit in the late 20s and they had to cut off construction at 29 floors. Still, it is a tall, solid and beautiful building with a wonderful lobby and a great history behind it. In the early 90s they refactored the building with new internal structure and re-did the outside with Tennesee Limestone. Who could have known they weren't going to need it? Only a pessimist!

I'm not implying that this disproves the description of Yagni, but it shows that sometimes you add hooks or invest a lot into your design making certain assumptions, and sometimes you find out for reasons not known at the time that you didn't need it.

-- PhilipEskelin

''In fact it supports YAGNI. The more your project learns, the less likely the hooks will be applicable. -- RonJeffries''

''It seems to me that refactoring the foundation or internal structure of a building is apt to be more expensive than refactoring the foundation or structure of a program. Perhaps YAGNI doesn't make that much sense in the context of architecture?''

Correcto. Refactoring and evolutionary design rely on the cost of change being low. It's usually not low in certain aspects of physical construction. -- rj

But see the book HowBuildingsLearn, which is all about refactoring buildings after their initial construction. -- JohnBrewer