Patterns of Cabinet Making Architecture
A master cabinet maker (my father) sent me a book, Cabinet Making for Beginners, because he knew I needed help with the fundamentals of cabinet making. I wanted to make a dresser for the boys. And while I have a few crude examples of casework to show for my trial and error in the garage, I knew there was a lot I didn't know about bringing together many of the elements necessary to make something like a chest of drawers, and to do so "properly".
Originally published in the 1940's (with many later editions in the 1970's--of which I have one), this book delivers. It presents some fundamentals of tools, basic techniques, joints, then goes through the three major structural aspects of cabinet making (frame, stool, box). The best techniques are presented for a variety of situations, with some lesser quality alternative approaches shown for "cheaper work."
As I work with wood, I'm often thinking about my day job. I have thoughts about how nice it is to have some autonomy and control over my work vs. the endless stream of compromise I wrestle with at work all day. But often I think about the similarities between building a wooden box and a web site. Oh, and I'm a tool junkie.
Cabinet Making for Beginners presents the subject of cabinet making much the say way we talk about "patterns" techniques in programming. The cabinet making trade has been refined over literally hundreds of years. And while times change (modern materials and adhesives make some of the requisite construction patterns 100 years ago obsolete now), books like this represent a distillate of the best patterns that have weathered the test of time.
I am a firm believer that good programmers should be able to see major structures in their code. This is part of why I believe white boards are as important to a team of software developers as is electricity (possibly more so).
This book talks about cabinet making in the same way an experienced software architect would talk about software. He compares and contrasts various techniques in the context of design principles and non-functional constraints. In the case of wood, these are things such as the seasonal expansion and contraction of the wood. He talks about alternatives as compromise, and discusses differences between materials and techniques and how they affect the design.
We can learn lessons from craftsmen going back hundreds of years. Their concern for the structural integrity of their products are not always echoed in the software world. I believe "software architecture" should be treated a separate topic in school. While software is a very different material than wood, and while the business is different enough that one shouldn't get too carried away with analogy, alternative domains of engineering and craftsmanship are worth study and thought.
Originally published in the 1940's (with many later editions in the 1970's--of which I have one), this book delivers. It presents some fundamentals of tools, basic techniques, joints, then goes through the three major structural aspects of cabinet making (frame, stool, box). The best techniques are presented for a variety of situations, with some lesser quality alternative approaches shown for "cheaper work."
As I work with wood, I'm often thinking about my day job. I have thoughts about how nice it is to have some autonomy and control over my work vs. the endless stream of compromise I wrestle with at work all day. But often I think about the similarities between building a wooden box and a web site. Oh, and I'm a tool junkie.
Cabinet Making for Beginners presents the subject of cabinet making much the say way we talk about "patterns" techniques in programming. The cabinet making trade has been refined over literally hundreds of years. And while times change (modern materials and adhesives make some of the requisite construction patterns 100 years ago obsolete now), books like this represent a distillate of the best patterns that have weathered the test of time.
I am a firm believer that good programmers should be able to see major structures in their code. This is part of why I believe white boards are as important to a team of software developers as is electricity (possibly more so).
This book talks about cabinet making in the same way an experienced software architect would talk about software. He compares and contrasts various techniques in the context of design principles and non-functional constraints. In the case of wood, these are things such as the seasonal expansion and contraction of the wood. He talks about alternatives as compromise, and discusses differences between materials and techniques and how they affect the design.
We can learn lessons from craftsmen going back hundreds of years. Their concern for the structural integrity of their products are not always echoed in the software world. I believe "software architecture" should be treated a separate topic in school. While software is a very different material than wood, and while the business is different enough that one shouldn't get too carried away with analogy, alternative domains of engineering and craftsmanship are worth study and thought.
posted by Steve at 3:01 PM
0 Comments:
Post a Comment
<< Home