Return to Answer

That is where design patterns came from.

The person that allegedly introduced the concept to the world was Christopher Alexander in his book "A Pattern Language: Towns, Buildings, Construction" in 1977. From there, the Gang of Four (GoF) picked it up, and the rest is history.

Even now during lectures and in software development and architecture books analogies between the construction world and the software development world keep prevailing.

Some analogies and references I can think of or recall:

• For example, changing requirements during the construction of a building it would perhaps become more evident to the client how absurd this is, e.g.: "OH, and I want a garage instead of where the kitchen you just finished is".
• Temporary aids such as scaffolding (meaning in construction world|software development)
• Clients cannot keep adding features without it costing them, lots of times they want stuff done for free, and sometimes we are dumb enough to accept; that just couldn't happen in the construction world (see requirements creep).
• The roles in software development: the architect is central to the design of the solution; consultor and contractor can be interchangeable terms; the workers are the programmers.
• The client cannot provide accurate requirements in both cases.
• Budgets and time estimates are often wrong.
• The product cannot be really seen in its true form until the end.
• A building might have construction faults after built, the same way software has bugs.
• If the product is badly done, sometimes it is preferrable to demolish and start over than fixing it.
• Not knowing about the actual and real outcomes of poor quality work, the client wants the cheapest solution.
• Open Source. I was just watching this talk from Doc Searls called "Why All Business Will Be Based on Open Source" where he tells how the construction community shares techniques and general knowledge instead of patenting them much like the open source community, even when some stuff in buildings contain proprietary products built-in.
• Projects turn out better for everyone if the client is involved actively.

(If more come to mind, I'll add them.)

There are some who don't think the general analogy is correct, a recommended reading for this is The Software Construction Analogy is Broken. Also, there is a question about this on SO titled What's wrong with the analogy between software and building construction?.

That is where design patterns came from.

The person that allegedly introduced the concept to the world was Christopher Alexander in his book "A Pattern Language: Towns, Buildings, Construction" in 1977. From there, the Gang of Four (GoF) picked it up, and the rest is history.

Even now during lectures and in software development and architecture books analogies between the construction world and the software development world keep prevailing.

Some analogies and references I can think of or recall:

• For example, changing requirements during the construction of a building it would perhaps become more evident to the client how absurd this is, e.g.: "OH, and I want a garage instead of where the kitchen you just finished is".
• Temporary aids such as scaffolding (meaning in construction world|software development)
• Clients cannot keep adding features without it costing them, lots of times they want stuff done for free, and sometimes we are dumb enough to accept; that just couldn't happen in the construction world (see requirements creep).
• The roles in software development: the architect is central to the design of the solution; consultor and contractor can be interchangeable terms; the workers are the programmers.
• The client cannot provide accurate requirements in both cases.
• Budgets and time estimates are often wrong.
• The product cannot be really seen in its true form until the end.
• A building might have construction faults after built, the same way software has bugs.
• If the product is badly done, sometimes it is preferrable to demolish and start over than fixing it.
• Not knowing about the actual and real outcomes of poor quality work, the client wants the cheapest solution.
• Open Source. I was just watching this talk from Doc Searls called "Why All Business Will Be Based on Open Source" where he tells how the construction community shares techniques and general knowledge instead of patenting them much like the open source community, even when some stuff in buildings contain proprietary products built-in.
• Projects turn out better for everyone if the client is involved actively.

(If more come to mind, I'll add them.)

There are some who don't think the general analogy is correct, a recommended reading for this is The Software Construction Analogy is Broken. Also, there is a question about this on SO titled What's wrong with the analogy between software and building construction?.

That is where design patterns came from.

The person that allegedly introduced the concept to the world was Christopher Alexander in his book "A Pattern Language: Towns, Buildings, Construction" in 1977. From there, the Gang of Four (GoF) picked it up, and the rest is history.

Even now during lectures and in software development and architecture books analogies between the construction world and the software development world keep prevailing.

Some analogies and references I can think of or recall:

• For example, changing requirements during the construction of a building it would perhaps become more evident to the client how absurd this is, e.g.: "OH, and I want a garage instead of where the kitchen you just finished is".
• Temporary aids such as scaffolding (meaning in construction world|software development)
• Clients cannot keep adding features without it costing them, lots of times they want stuff done for free, and sometimes we are dumb enough to accept; that just couldn't happen in the construction world (see requirements creep).
• The roles in software development: the architect is central to the design of the solution; consultor and contractor can be interchangeable terms; the workers are the programmers.
• The client cannot provide accurate requirements in both cases.
• Budgets and time estimates are often wrong.
• The product cannot be really seen in its true form until the end.
• A building might have construction faults after built, the same way software has bugs.
• If the product is badly done, sometimes it is preferrable to demolish and start over than fixing it.
• Not knowing about the actual and real outcomes of poor quality work, the client wants the cheapest solution.
• Open Source. I was just watching this talk from Doc Searls called "Why All Business Will Be Based on Open Source" where he tells how the construction community shares techniques and general knowledge instead of patenting them much like the open source community, even when some stuff in buildings contain proprietary products built-in.

(If more come to mind, I'll add them.)

There are some who don't think the general analogy is correct, a recommended reading for this is The Software Construction Analogy is Broken. Also, there is a question about this on SO titled What's wrong with the analogy between software and building construction?.

That is where design patterns came from.

The person that allegedly introduced the concept to the world was Christopher Alexander in his book "A Pattern Language: Towns, Buildings, Construction" in 1977. From there, the Gang of Four (GoF) picked it up, and the rest is history.

Even now during lectures and in software development and architecture books analogies between the construction world and the software development world keep prevailing.

Some analogies and references I can think of or recall:

• For example, changing requirements during the construction of a building it would perhaps become more evident to the client how absurd this is, e.g.: "OH, and I want a garage instead of where the kitchen you just finished is".
• Temporary aids such as scaffolding (meaning in construction world|software development)
• Clients cannot keep adding features without it costing them, lots of times they want stuff done for free, and sometimes we are dumb enough to accept; that just couldn't happen in the construction world (see requirements creep).
• The roles in software development: the architect is central to the design of the solution; consultor and contractor can be interchangeable terms; the workers are the programmers.
• The client cannot provide accurate requirements in both cases.
• Budgets and time estimates are often wrong.
• The product cannot be really seen in its true form until the end.
• A building might have construction faults after built, the same way software has bugs.
• If the product is badly done, sometimes it is preferrable to demolish and start over than fixing it.
• Not knowing about the actual and real outcomes of poor quality work, the client wants the cheapest solution.
• Open Source. I was just watching this talk from Doc Searls called "Why All Business Will Be Based on Open Source" where he tells how the construction community shares techniques and general knowledge instead of patenting them much like the open source community, even when some stuff in buildings contain proprietary products built-in.
• Projects turn out better for everyone if the client is involved actively.

(If more come to mind, I'll add them.)

There are some who don't think the general analogy is correct, a recommended reading for this is The Software Construction Analogy is Broken. Also, there is a question about this on SO titled What's wrong with the analogy between software and building construction?.

That is where design patterns came from.

The person that allegedly introduced the concept to the world was Christopher Alexander in his book "A Pattern Language: Towns, Buildings, Construction" in 1977. From there, the Gang of Four (GoF) picked it up, and the rest is history.

Even now during lectures and in software development and architecture books analogies between the construction world and the software development world keep prevailing.

Some analogies and references I can think of or recall:

• For example, changing requirements during the construction of a building it would perhaps become more evident to the client how absurd this is, e.g.: "OH, and I want a garage instead of where the kitchen you just finished is".
• Temporary aids such as scaffolding (meaning in construction world|software development)
• Clients cannot keep adding features without it costing them, lots of times they want stuff done for free, and sometimes we are dumb enough to accept; that just couldn't happen in the construction world (see requirements creep).
• The roles in software development: the architect is central to the design of the solution; consultor and contractor can be interchangeable terms; the workers are the programmers.
• The client cannot provide accurate requirements in both cases.
• Budgets and time estimates are often wrong.
• The product cannot be really seen in its true form until the end.
• A building might have construction faults after built, the same way software has bugs.
• If the product is badly done, sometimes it is preferrable to demolish and start over than fixing it.
• Not knowing about the actual and real outcomes of poor quality work, the client wants the cheapest solution.

(If more come to mind, I'll add them.)

There are some who don't think the general analogy is correct, a recommended reading for this is The Software Construction Analogy is Broken. Also, there is a question about this on SO titled What's wrong with the analogy between software and building construction?.

That is where design patterns came from.

The person that allegedly introduced the concept to the world was Christopher Alexander in his book "A Pattern Language: Towns, Buildings, Construction" in 1977. From there, the Gang of Four (GoF) picked it up, and the rest is history.

Even now during lectures and in software development and architecture books analogies between the construction world and the software development world keep prevailing.

Some analogies and references I can think of or recall:

• For example, changing requirements during the construction of a building it would perhaps become more evident to the client how absurd this is, e.g.: "OH, and I want a garage instead of where the kitchen you just finished is".
• Temporary aids such as scaffolding (meaning in construction world|software development)
• Clients cannot keep adding features without it costing them, lots of times they want stuff done for free, and sometimes we are dumb enough to accept; that just couldn't happen in the construction world (see requirements creep).
• The roles in software development: the architect is central to the design of the solution; consultor and contractor can be interchangeable terms; the workers are the programmers.
• The client cannot provide accurate requirements in both cases.
• Budgets and time estimates are often wrong.
• The product cannot be really seen in its true form until the end.
• A building might have construction faults after built, the same way software has bugs.
• If the product is badly done, sometimes it is preferrable to demolish and start over than fixing it.
• Not knowing about the actual and real outcomes of poor quality work, the client wants the cheapest solution.
• Open Source. I was just watching this talk from Doc Searls called "Why All Business Will Be Based on Open Source" where he tells how the construction community shares techniques and general knowledge instead of patenting them much like the open source community, even when some stuff in buildings contain proprietary products built-in.

(If more come to mind, I'll add them.)

There are some who don't think the general analogy is correct, a recommended reading for this is The Software Construction Analogy is Broken. Also, there is a question about this on SO titled What's wrong with the analogy between software and building construction?.