it's difficult grouping books together (and harder still to find snappy titles for the categories) - these are books related to computing that don't fit into any other category.
these are links to an essay for the "general reader" that introduces some of the ideas behind programming languages. it is loosely structured around a review of the book design patterns (gamma et al), but don't expect too much about design or patterns.
download the article in...
if you are using a windows pc the pdf version is most likely to work; linux and other unix users might prefer the other formats.
this interesting little book compares the internet with the telegraph. like "zen and the art of motorcycle maintenance" the best bits are the incidental details (in this case how the telegraph evolved, rather than how to fix your bike).
for such an obviously good idea (in retrospect) the telegraph took a long time to get off the ground. the two reasons i could see were: first, that the "scientific community" was mainly a collection of poorly organised (if brilliant) amateurs, divorced from the general business community; second that surprisingly little was known about electricity - i didn't realise that something so commonplace now took so long to understand in depth.
but, in the end, things did take off. one of the main beneficiaries was the gutta-percha company, which had a practical monopoly on the supply of the rubber best suited to insulating the lines. while that name may not be well-known, the company now trades as cable and wireless... (assuming the book is right!).
leaving the interesting details aside, how useful is the comparison between internet and telegraph? tom standing points to the optimistic claims made at the time, that the telegraph would spread global peace and understanding, and so end war and famine, and compares it with similar claims for the 'net. clearly both are bunkum - remember that the majority of people have not even used a telephone.
more interestingly, what will supercede the internet? the telegraph collapsed with the advent of the telephone. what will kill the web?
previous latest addition here.
hofstadter's books - at least, this and metamagical themas - are being sold off cheap here in the uk. perhaps there are new editions coming out? anyway, i'm not a great fan of hofstadter's writing, his whimsy leaves me cold, but at a third of the price there was nothing to lose...
metamagical themas, which is a collection of articles from scientific american, isn't up to much - although i sympathise with much of what he says, especially the social comments (it also prompted me to write this software).
fluid concepts and creative analogies is also a collection of papers, with new prefaces, but is more focused, staying closer to hofstafter's professional expertise, and much more interesting.
first, it is interesting as a book about hofstadter - a man who obviously cares deeply about his work - and the ai (cognitive science) community. there are several articles where it is clear that he feels other projects are over-rated while his are given insufficient consideration.
hofstadter's writing on creativity and genius clearly reflects his own self image. still, many seem (at least to me) correct and the general slant is illuminating, as are the occasional snippets of autobiographical detail. this is what it is like to be the (precocious?) son of a nobel prize physicist.
second, it describes an interesting architecture for ai programs: something that sits half-way between "classical" algorithms and neural nets. a "slip-net" is used to record the program's current knowledge - each node in the net represents a concept and the links represent influences.
within a workspace, input data is grouped and analysed. bottom-up analysis (equivalent to input to a net) of the input data changes the "activation" of nodes which then decays, with "deeper" concepts enduring for longer. activation also changes the "lengths" of links and invokes top-down analysis (possibly equivalent to feedback in a net?) focusing on concepts close to the activated nodes.
the fluctuation of activation on the slip-net and structure within the workspace over time is measured by "temperature" and the stochastic selection of particular sections of analsysis code ("codelets") is modulated in a similar to way to simulated annealing (although in this case the temperature is a derived property which can increase and decrease).
using explicit code and concepts, rather than learnt weights, opens the program's operation to inspection - hofstadter uses rather anthropomorphic language in doing so. presumably he expects that either nesting or a larger, self-referencing slip-net will lead to introspection and consciousness.
it could be argued that explicit concepts allow a programmer to add their own knowledge, passing on the training of their own neural net (if that is indeed how the brain works) and so avoiding constructing and training a net that, to have equivalent power, might be impossibly complex. the obvious question - which is not clearly answered - is to what degree fine tuning of the many model parameters is necessary to get useful results.
if there is one clear difference between neural nets and the architecture proposed by hofstadter (and his group, who seem to do most of the coding) it is that, in a net, all processing is done during training, yet this is obviously not how our own brains work, at least at the highest levels (you have not, for example, read all of this paragraph before understanding any of it). this may be an important point, or it may simply reflect the very primitive state of current neural nets - at some point they must start to modify themselves when in use.
the sketchiness of this review reflects the huge amount of information within the book - it includes examples of a couple of implementations that focus on particular domains and finishes with a sketch of the current, more ambitious project, letter spirit. it will be interesting to see how well the architecture scales as, despite the claims made, there seem to be a lot of very delicately balanced coding - explicit knowledge that makes the programs more powerful than current neural nets, but which also raises questions about how larger and larger systems can be built without learning.
Teaser for Slashdot's "above the fold": The second edition of Alistair Cockburn's "Agile Software Development" was released earlier this year. Does it add significantly to the first edition? Who should read it? And is it clear yet what "Agile" means? The answers: Maybe; Everyone; Ri. Amplification and justification below...
This excellent, but imperfect, book might make more sense read backwards - you would start (at the end) with useful, concrete ideas about how to improve the way you make software, progress to a more general discussion, and end with the unifying principles of Shu, Ha and Ri.
Instead, Cockburn starts by explaining those terms. He says that they are from Aikido. Someone who understand them in their original context may find the following (my own summary) to be crude (or plain wrong), but they are central to this book and to Agile as a whole:
Although he never comes out and flatly states it, Cockburn clearly implies that Agile development is all about the Ri. I think he's right: that makes this book worth buying, reading, and passing on to others.
But this is all rather vague (another reason to read the book backwards is that it's much easier to tolerate this kind of hand-waving when you've seen some concrete facts; start at the beginning and you face not just this "wisdom", but some of Cockburn's own poetry - Paul Neil Milne Johnstone has a posse). Back to earth. What does this mean, in practical terms? And what does this say about "Agile"?
First rule of Agile: there are no rules. There are too many variables for any one process to be always right. Instead, you do what works in a particular context. Results matter. It's not who uses the latest catchphrase. It's not winning boardroom bingo. It is about getting results out of the door.
How do you get there? Is "Agile" more than the empty tautology "it's best to do the right thing"? After all, while we want to be Ri, we start at Shu. Cockburn provides two answers.
First, reflect. Learn from your own group's experiences. Look at what you do well. Build on it. If reflection fails, reflect on that. Cockburn repeatedly emphasises the need for personal safety - that people need to feel safe to express what they think.
Second, steal. Learn from other groups' experiences. The second half of the book, roughly, discusses possible ideas. These tend to be the "traditional" Agile themes: communication; lightweight documentation; information radiators; pair programming; etc. Useful information when you're at the Shu level.
So this book is targeted at people responsible for process. People that influence a company's culture. People who aim to create an environment in which "The Cooperative Game" - Cockburn's term - can be played well.
Pick up a copy at your local bookstore and you'll see that there are grey "tab marks" printed on some page edges. These indicate new content (the unmarked pages are the original text which has been kept, more or less verbatim). In general the updates are not that substantial, but chapter 5.1 - a retrospective (with notes on various practical cases) - is the exception.
This new section includes reports from others responsible for improving agility. They are in broad consensus: the Cooperative Game cannot be dictated. It must be cultivated; grown from the roots.
Which is why this is also a book for developers. It recognises that everyone can make a difference. At various points in the book Cockburn addresses the question "what do I do about this?" and he's talking to everyone.
I am a programmer working in a distributed, open-source project. There are times when I take a walk round the block to shrug off the less-than-helpful comments of a co-worker, or some anti-pattern in the code, or [any programmer can insert their own examples here - my co/workers are a great bunch, these problems occur everywhere]. Reading a book like this helps keep me sane: it helps me understand how I miscommunicate, and how to communicate better; it lets me understand the (valuable!) role each person plays in our process (before that, it helped me see what our process is); it reassures me that communication in a distributed team is hard and it gives me ideas to help solve these issues. Although, having written that, I think Cockburn could profit from a study of successful global teams.
Your problems will be different, but the best way to solve them will be the same - through careful thought and reflection. And at heart, that is what this book is about. Cognitive Behavioural Therapy for software development.
So this is a good book. It recognises that things go wrong; it admits there is no one size fits all patented wonder potion magical cure; it reaches the logical conclusion, you have to think; it goes on to discuss possible solutions.
But it's not perfect. One of the more amusing sections describes Cockburn's experience producing the previous version - he tried an Agile approach to publishing which met the (very tight) deadline, but alienated his copy-editor. Now I don't know what a copy-editor does, but if he was relying on her to remove duplications, rewrite cliches, or improve metaphors, well, he might not have found the optimal process. And it is a pity that the original text was not more completely revised for this edition.
Two final conclusions. One is that the waterfall model is "Agile" if it's the best approach for the circumstances. The other is that you should be suspicious of anyone trying to sell a single, perfect, recipe.
Disclaimer - I obtained a free copy of this book on condition that I review it.