139
Extreme programming
Code as prototype for software
Code as prototype for software
0
terms
2
notes
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 [...]
[...] 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 [...]
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)
[...] 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)