Regarding management techniques, I think you are right that Taylorist approaches are used in the software industry, however one only needs to look over the literature to see the lack of success in this area. Software engineering is still a relatively recent discipline and there is still, today, a reliance on the super-human efforts of a small cadre of programmers within a project a la Ullman’s The Bug. The lack of a silver bullet in software programming still eludes the managers, who are therefore reliant on programmers who know far more about the system they are working on than any level of management. Whilst not wanting to be too optimistic or celebratory about this, after all programmers can, and often are, very mercenary in these situations, nonetheless, this is an interesting moment for those interesting in studying software, and of course, the potential for radical politics also remains radically open.

I talk about some of the kinds of things I think would be useful in a humanities perspective for teaching some notions of ‘code’ through the idea of ‘iteracy’. This might not be useful for CS students, of course, who require a much firmer grasp of computational principles, but this you might find interesting:

http://stunlaw.blogspot.com/2011/09/iteracy-reading-writing-and-running.html

and an attempt to implement the ideas in Zajal code:

http://stunlaw.blogspot.com/2012/02/iteracy-attempt-to-read-write-and-build.html

I wonder if Livecoding might be a nice way into teaching programming though…

Yes, I think obfuscated code is really quite revealing when it comes to understanding what programming languages are and how they function in terms of logic, but my point is that as practitioners, we are constantly struggling against the “creeping obfuscation” that is the result of time constraints, differences in style between programmers, bad habits, sheer complexity, forgetting, and so on. Trying to make our code readable is so much part of what we try to do every day when writing software that I think that it merits some attention as well. The playful aspects of programming should not make us forget that most programming work is real drudgery – shifting data from A to B, designing interface states (the most horribly dull work in my view), etc. – that is embedded in commercial pressures and cost constraints. Writing readable code is part of the logic of control and efficiency (building things that work) that computation is largely embedded in – including open source for that matter… Unit tests and similar techniques can indeed be approached from the logic of computation and the theory of software design, but there is also the fact that, in practice, they are used to discipline bad programmers into writing working code. A management technique for getting at least some productivity out of the 50+% of CS students that get a degree without actually being able to design a non-trivial piece of software. Looking at this “in practice” – which is really not very glorious – is what I’m suggesting. I guess that I’m just a bit cynical after years of writing code for food and teaching programming…

cheers!
B.

Yes, I read that and cite it at various points in the article! Fully agree with your argument there.

best,
B.

This I then link to Callon and Latour (via Boltanski and Thevenot) to the notion of ‘tests’ – implying that it is crucially the running of these obfuscated code programs that shows that they *are* code at all (legitimate tests), rather than gibberish. The fact that they are unreadable by humans and yet testable is very interesting, more so as they become aesthetic objects in themselves as the programmers start to create ASCII art both as a way of making the code (unreadable), now readable as an image, but also adding another semiotic layer to the meaning of the code’s function. Equally I discuss the nature of scoping that these tests imply (tests of strength) and the fact that the mutability of code is constrained through limits placed in terms of the testing and structure of the competition, but also how these restrictions which serve as what Boltanski and Thevenot would call ‘tests of strength’, which themselves are reflexively played with in terms of clever programming that works at the borderline of acceptability for programming practices.

Best

David

As a technologist, I am puzzled. Why is this so? Is there an anomaly in Google’s algorithm? Or is it something with the web content it filters and it is indicative of something that is really happening (e.g. many web pages detailing how crooks pose as agents for this specific insurance company)?

As a law student (in North America) I tend to agree with the judge’s decision. Google should definitely pick up its mess and filter algorithmic results like it obviously does in related areas of activity; and ideally, without revealing their “secret sauce”, come up with an explanation for the odd result and solve the tech puzzle. Google’s arrogance has earned them a condemnation. I just wish the fine was higher. $65K is pocket money for G.

With RequestPolicy, the third-party sites are blocked by default and you can activate them on a case by case basis if you need them to know you are there.