Mechanics, Software, and Luddites
Dec. 11th, 2011 02:23 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
foolish_m0rtalOkay, I had to write this paper for my Science, Technology, and Society class (a writing class for engineers), and I'm actually kind of proud of it. It investigates approaches to software development against a book we had to read called Shop Class As Soulcraft that addresses the state and history of craft or trade vocations such as mechanics. I don't usually post college work up here, but whatever. It's really as much for my records as anything.
The computer science approach to building systems, large coding projects, and even user interfaces have emphasized the need for abstraction and encapsulation. Abstraction is the concept of accessing the highest level of code that manipulates larger and more complicated batches of code underneath the surface. It removes the sense of an entire code system and creates instead an array of portals that programmers must use to access aspects of the code. Encapsulation takes this idea and creates what is called a 'black box,' a piece of code with inputs and outputs and no indication of the processing code inside. The popular software development book The Mythical Man-Month suggests that this approach makes sharing code more efficient, adds a layer of security, and promotes easier and quicker maintenance. This is a software implementation of the interchangeable parts concept that allows the programmer to remove a piece of code, work on it, and snap it back into place without disturbing the rest of the system.
The mapping from these software concepts in computer science to a mechanic's sense of the word is quite similar. The concepts in computers science keep the code 'under the hood' and inaccessible to the programmer the programmer to reduce the level of technical knowledge required to implement the code, protect the code from tampering, and made building code easier by reducing it into blocks. It is an eerily similar sibling to Matthew B. Crawford's description of the large metal box under a car's bonnet that abstracts many of the machinery's inner workings. Many of the challenges mechanics in the past and present have faced with knowledge trickling up to the management level are the same exact challenges computer scientists are facing as software becomes larger and more complicated.
Crawford glorifies the human right to have the knowledge and manual skill to repair his own machines. He claims that being able to fix and understand your own automobile or radio returns a sense of dominance that has been taken away by the slow push towards mechanical complexity and mechanical abstraction. However, he falls into the risk of being labeled a Luddite, a term he might even welcome.
Luddites in the 19th century were artisans who felt threatened by the Industrial Revolution's introduction of automated machines such as looms that required only unskilled labor for operation. The Luddites amassed and protested the new changes by destroying many looms and claiming that technology was deskilling the workers in the industry while making craftsmen obsolete. In this, they were not entirely wrong. A love and promotion of technology without restraint has often preceded a flux in the market; the machine abstracts away much of the technical complexity that would otherwise require a skilled worker. Higher-skilled workers may find the machine has replaced them while lesser-skilled workers can find jobs without needing as much of the prerequisite technical knowledge. If we follow the machinery to code mapping we've previously defined, the plight of the Luddite has become the modern day plight of programmers. The 'machinery,' i.e. the abstracted and encapsulated blocks of code, have allowed companies to send code overseas and create jobs for entry-level coders who can do their jobs without needing to understand the entire system. There is no ownership of an entire system.
However, there is a balance between abstraction and gaining a greater sense of agency. For example, while Crawford's desire to fix motorcycles himself is admirable, the motorcycles and automobiles of history are a far cry from the high-tech automobiles of today. Automobiles now have complex electronic systems that run through software. We cannot simply disregard these advancements because they have made cars safer (e.g. anti-lock brakes) and easier to control (e.g. power streering) than cars of the past. Because these components are the coder's area of expertise instead of the mechanics, some abstraction is necessary here to facilitate maintaining the car. Just as with code, this abstraction lets mechanics find parts easily without needing to know the code behind them, adds a layer of security to the code, and allows for quicker maintenance. The same is true of large computer systems.
There is a beloved dream in the computer science field of creating a startup in a garage or basement, starting small and having access to all parts of the system. These startups are considered the ideal; we value a startup creator's sense of autonomy, love of the art, and technical knowledge required to build an entire system from scratch. We like to believe that this is how all success stories happen, but in this day and age it is not feasible. Software systems have simply become too large and are connected to each other through the Internet and phone lines, which facilitate a communication among software systems that has become essential. Good programmers are encouraged not only to implement abstraction and encapsulation but also to code in a uniform fashion; sharing code and working on large systems with multiple people means you must stick to coding conventions. Some of these include new line brackets for method blocks (where the encapsulating brackets to house a block of code are written on their own lines) and camelback variable declarations (with multiple-word variables declared with certain cases. e.g. shopClass). No matter how trivial these conventions are, coders are frustrated when a team member doesn't follow them and see them as inferior coders.
This is exactly what Crawford highlights in his narrative of a schoolteacher taking over his father's shop; the creation of machinery and the piecing together of parts that allow the 'spark of life' to flow through it is difficult and must be done with care. However, just like the small mechanics shops that Crawford prizes, computer science has its own kind of neo-Luddism. Underneath the concepts of uniformity, we have hackers and open-source projects that seek to upset the norm and regain coding agency. Linux is one of the most famous examples of this. These groups have not created negative flux in the market and have even contributed to the way we look at creating software. We can only wait and see how this 'grassroots' coding will impact concepts of abstraction and encapsulation in future software initiatives.
The computer science approach to building systems, large coding projects, and even user interfaces have emphasized the need for abstraction and encapsulation. Abstraction is the concept of accessing the highest level of code that manipulates larger and more complicated batches of code underneath the surface. It removes the sense of an entire code system and creates instead an array of portals that programmers must use to access aspects of the code. Encapsulation takes this idea and creates what is called a 'black box,' a piece of code with inputs and outputs and no indication of the processing code inside. The popular software development book The Mythical Man-Month suggests that this approach makes sharing code more efficient, adds a layer of security, and promotes easier and quicker maintenance. This is a software implementation of the interchangeable parts concept that allows the programmer to remove a piece of code, work on it, and snap it back into place without disturbing the rest of the system.
The mapping from these software concepts in computer science to a mechanic's sense of the word is quite similar. The concepts in computers science keep the code 'under the hood' and inaccessible to the programmer the programmer to reduce the level of technical knowledge required to implement the code, protect the code from tampering, and made building code easier by reducing it into blocks. It is an eerily similar sibling to Matthew B. Crawford's description of the large metal box under a car's bonnet that abstracts many of the machinery's inner workings. Many of the challenges mechanics in the past and present have faced with knowledge trickling up to the management level are the same exact challenges computer scientists are facing as software becomes larger and more complicated.
Crawford glorifies the human right to have the knowledge and manual skill to repair his own machines. He claims that being able to fix and understand your own automobile or radio returns a sense of dominance that has been taken away by the slow push towards mechanical complexity and mechanical abstraction. However, he falls into the risk of being labeled a Luddite, a term he might even welcome.
Luddites in the 19th century were artisans who felt threatened by the Industrial Revolution's introduction of automated machines such as looms that required only unskilled labor for operation. The Luddites amassed and protested the new changes by destroying many looms and claiming that technology was deskilling the workers in the industry while making craftsmen obsolete. In this, they were not entirely wrong. A love and promotion of technology without restraint has often preceded a flux in the market; the machine abstracts away much of the technical complexity that would otherwise require a skilled worker. Higher-skilled workers may find the machine has replaced them while lesser-skilled workers can find jobs without needing as much of the prerequisite technical knowledge. If we follow the machinery to code mapping we've previously defined, the plight of the Luddite has become the modern day plight of programmers. The 'machinery,' i.e. the abstracted and encapsulated blocks of code, have allowed companies to send code overseas and create jobs for entry-level coders who can do their jobs without needing to understand the entire system. There is no ownership of an entire system.
However, there is a balance between abstraction and gaining a greater sense of agency. For example, while Crawford's desire to fix motorcycles himself is admirable, the motorcycles and automobiles of history are a far cry from the high-tech automobiles of today. Automobiles now have complex electronic systems that run through software. We cannot simply disregard these advancements because they have made cars safer (e.g. anti-lock brakes) and easier to control (e.g. power streering) than cars of the past. Because these components are the coder's area of expertise instead of the mechanics, some abstraction is necessary here to facilitate maintaining the car. Just as with code, this abstraction lets mechanics find parts easily without needing to know the code behind them, adds a layer of security to the code, and allows for quicker maintenance. The same is true of large computer systems.
There is a beloved dream in the computer science field of creating a startup in a garage or basement, starting small and having access to all parts of the system. These startups are considered the ideal; we value a startup creator's sense of autonomy, love of the art, and technical knowledge required to build an entire system from scratch. We like to believe that this is how all success stories happen, but in this day and age it is not feasible. Software systems have simply become too large and are connected to each other through the Internet and phone lines, which facilitate a communication among software systems that has become essential. Good programmers are encouraged not only to implement abstraction and encapsulation but also to code in a uniform fashion; sharing code and working on large systems with multiple people means you must stick to coding conventions. Some of these include new line brackets for method blocks (where the encapsulating brackets to house a block of code are written on their own lines) and camelback variable declarations (with multiple-word variables declared with certain cases. e.g. shopClass). No matter how trivial these conventions are, coders are frustrated when a team member doesn't follow them and see them as inferior coders.
This is exactly what Crawford highlights in his narrative of a schoolteacher taking over his father's shop; the creation of machinery and the piecing together of parts that allow the 'spark of life' to flow through it is difficult and must be done with care. However, just like the small mechanics shops that Crawford prizes, computer science has its own kind of neo-Luddism. Underneath the concepts of uniformity, we have hackers and open-source projects that seek to upset the norm and regain coding agency. Linux is one of the most famous examples of this. These groups have not created negative flux in the market and have even contributed to the way we look at creating software. We can only wait and see how this 'grassroots' coding will impact concepts of abstraction and encapsulation in future software initiatives.
