Welcome to Bookmarker!

This is a personal project by @dellsystem. I built this to help me retain information from the books I'm reading.

Source code on GitHub (MIT license).

139

Extreme programming

Code as prototype for software

0
terms
2
notes

Mackenzie, A. (2006). Extreme programming. In Mackenzie, A. Cutting Code: Software and Sociality. Peter Lang Inc., International Academic Publishers, pp. 139-168

140

[...] the experience of programming seems to be somewhat different. Ellen Ullman (1997) expresses it this way: "You write some code, and suddenly there are dark, unspecified areas. All the pages of careful documents, and still, between the sentences, something is missing" (21). Rather than becoming mechanical or predictable, over the course of time the flows of information managed by software become more dynamic, complex and unstable. Increasingly, programmers interact with worlds that are not abstract, mechanical, formalized, or in any simple sense, globalized [...]

—p.140 by Adrian Mackenzie 6 years, 3 months ago

[...] the experience of programming seems to be somewhat different. Ellen Ullman (1997) expresses it this way: "You write some code, and suddenly there are dark, unspecified areas. All the pages of careful documents, and still, between the sentences, something is missing" (21). Rather than becoming mechanical or predictable, over the course of time the flows of information managed by software become more dynamic, complex and unstable. Increasingly, programmers interact with worlds that are not abstract, mechanical, formalized, or in any simple sense, globalized [...]

—p.140 by Adrian Mackenzie 6 years, 3 months ago
147

[...] The production of software has for decades been seen as resistant to industrial or Fordist techniques (e.g., Brooks 1995; see Aneesh 2001). The very term "software developer" conveys a certain open-endedness that software development methodologies attempt to close off. [...]

thought: the job of the software developer is precisely the limit of attempts to Taylorize it. like if something can be automated, then that doesn't take really take away from the software developer's job so much as add a tool to their arsenal. all the automatable stuff (as the result of trying to apply Fordist/Taylorist techniques) gets subsumed, submerged; the developer then works on top and treats it as a deeper, more solid base from which they can reach greater heights

at least, that's the way it SHOULD be treated. management may view it differently. it also depends on the capacity of the developer for climbing the metaphorical scaffold of tools (maybe at a certain point it's just beyond their ability, or desire)

idk just a thought (need to find someone who has written about this)

—p.147 by Adrian Mackenzie 6 years, 3 months ago

[...] The production of software has for decades been seen as resistant to industrial or Fordist techniques (e.g., Brooks 1995; see Aneesh 2001). The very term "software developer" conveys a certain open-endedness that software development methodologies attempt to close off. [...]

thought: the job of the software developer is precisely the limit of attempts to Taylorize it. like if something can be automated, then that doesn't take really take away from the software developer's job so much as add a tool to their arsenal. all the automatable stuff (as the result of trying to apply Fordist/Taylorist techniques) gets subsumed, submerged; the developer then works on top and treats it as a deeper, more solid base from which they can reach greater heights

at least, that's the way it SHOULD be treated. management may view it differently. it also depends on the capacity of the developer for climbing the metaphorical scaffold of tools (maybe at a certain point it's just beyond their ability, or desire)

idk just a thought (need to find someone who has written about this)

—p.147 by Adrian Mackenzie 6 years, 3 months ago