Month: December 2004

Well this was a worth reading. Some parts of the book seems to have been added just to reach an adequate size. Despite of this the book is able to shred some light on the 2000 elections, and the party who is driving the most powerful country on this Earth.I read some time ago another Moore’s book: Dude, Where’s My Country, more targeted at 9/11 facts. And it was a worth reading, too.
Michael style is direct and straightforward. Every important claim is documented through some reference.

This is the first book by Chomsky I read. To be precise this is a collection of Chomsky’s answers in a radio talkshow to listeners’ questions. From this answers you get Chomsky’s interpretation of the last century facts. You may not agree, nonetheless his interpretation is very fitting. Definitively a worth reading. What I didn’t like is that the Italian publisher added his entries in the associations list provided by Chomsky at the end of the book. The result is that you cannot distinguish from which are recommended by Chomsky and which are recommended by the publisher. I won’t add much because I think it is better everyone form his/her own opinion on this stuff.

This is the second book by Pratchett I read in original language. Pratchett is great, as usual, in clever entertainment. You don’t get just some funny jokes, but the plot depth and the characterization are up to the best novels I read. The plot is about godmothering vs. witchcraft. The usual witch party – Granny Weatherwax, Nanny Ogg and Magrat Garlick – is going to the distant city of Genua to perform some godmothering duties, having Magrat inherited a godmother fairy wand.
For the non-native-english reader the book is plenty of challenges. Witches speak odd word you aren’t likely to find in a conventional dictionary. The only way I found to get the sense of these tough parts is to go for the likely pronunciation and finding assonance with known words. Also there are some parts, some sentences you are sure are some sort of joke, pun or distortion of the like, but remain quite obscure.
Nonetheless the reading is really worth the effort… Reading twice or thrice the same page to (try to) get every bit of meaning lets you taste the book better and better.
Also expect big laugh, there are unforgettable moments which made me hilarious despite being in a crowded train carriage.

(This book is also available for free here). The Art of Unix Programming is about Unix culture and about old-style Unix programmers approach to design and interface their application. It is not, strictly speaking about programming (nor about art), but the title correctly propose the idea of a balanced approach based on good instincts and well behaved practices.
I wrote “old-style” because the author is strongly rooted in the Unix culture and more about text oriented stuff rather than interactive GUI. Also “old-style” was about sharing and community much like GNU/Linux today as opposing to proprietary Unixes which are about making money by selling software.
The author presents 17 rules considered the basics for Unix philosophy how these are driving development and why they are good. These rules are very close to software engineering principles. Call them rules, call them principles, what is important is that these are things worth doing.
Trying to tackle nearly everything is going on in Unix and abstracting from it in a generalization is not an easy tasks. And in the long run the book loses here and there some of the interest it triggers in the most entertaining pages. Even if Unix is not your main development environment, I think that some parts of the books are nonetheless worth reading. You can have an idea of the book by browsing it on-line before deciding if it’ll be your next buy.
The criticism about OO is appropriate. I mean every paradigm could promote bad habits and OO is not an exception. One of the bad habits of OO is to create too many layers of encapsulation and inheritance for the problem. Causing the resulting code to be encapsulated but obscure with too much spred mechanics. A good quote in the book, even if it hasn’t to be taken to letter, is “If you know what you’re doing, three layers is enough; if you don’t, even seventeen levels won’t help” – attributed to Michael Padlipsky (The Elements of Networking Style. iUniverse.com. 2000. ISBN 0-595-08879-1).

This is the book of the year I suppose, being in the international top ten for a while now. This was a Xmas present for my brother who has been so nice to lend it to me. The book is indeed addicting, to the point that you have to be really brave to drop it. I read it in 4 days only because I was forced to make some pauses.
Despite the excellent writing technique, I found it somewhat weak in logic. I mean more than one riddle is easy for the reader to solve well in advance of the characters. Also, it is not clear why the Evil One, while being too clever to organize all the script, miserably fails to uncover himself when he has the treasure in his hands.

My impression was that this is a manifesto book, as much as The Celestine Prophecy is a manifesto to the New Age ideology. The book is deeply descriptive of secret societies’ history and the Christian religion origin. I guess many facts reported are real.

But from a research point of view, I prefer a book such as The Templar Revelation, which is full of references to sources and material for further research.

This is the second book from Benni I read. And the second I like. The story is about a new live concert which has to be organized to revamp the Perpetual War which is starting to lose share in the audience. Unfortunately shamans and Spirits are in the island where the concert should take place.Benni writes with talent an entertaining, satirical and surreal novel. The world he describes is not our present one, but it is easy to recognize current politicians, countries and corporations in the clever parody.
As in Terra! it is not just about satire, but the story is there with an urgent message of being true, of we under siege of empty or fake values.
Unfortunately this book seems to be available in Italian only.

I bought this book beacuse I am fascinated by the alternative history books. What if the German had won the WWII? The subject is the same dealt with in the book Fatherland by Robert Harris. The difference is that Fatherland is set in Germany, while SS/GB is set in London, telling about invading forces trying to define and layout the new system scheme and the subjected people striving between the revolt and revenge desire and the need of a stable and safe everyday life.I found the book rather dull… as if there were no story to tell about. The main character is a famous detective in Scotland Yard now to the orders of the new boss – a German army general. The plot is about some atomic research and stealing of related documents. There is a general good potential for developing situations, but the writer seems to lightly ignore them, putting other meat on the bbq and going on like that.
Maybe I lack some history details about relevant WWII people in UK, so I missed too many links and goodies, or maybe too much went lost in the translation… Anyway I wouldn’t reccommend this book. (I just glanced through the Amazon reviews that are instead rather good).

Extreme programming never covinced me 🙂 I read Kent Beck’s book. I found it very well thought, with a good presentation. On some topics I agreed – unit test would have been a great thing to have in many projects I’ve worked on. Also some YAGNI (“You Aren’t Gonna Need It”) would have had helped sometimes. Also I found quite clever the idea of on-site customer, even if not so practical. Anyway I couldn’t imagine my programming life in pair. I have my rythm and I like to code alone. I’m ready to join colleagues if any of us would like to share thoughts or has some question, but programming was meant to be done alone :-).Another two points I wasn’t very comfortable with were no written requirements and no planning. I coulnd’t see how this kind of methodology could be applied to the environment where I’ve been working. We programmers strove to get specification and requirements in a written form. Our customers – artist and game designers were too fast in changing their minds, adding new requirements, and no so precise in their requests.
No plan conflicted with my idea of preparing for the future, choosing the right path to get to the goal.
Well, this book is a critique to the whole Extreme Programming, both on methodology and results. I recommend this book, even if its size could have been halved by removing parody songs (quite boring if you don’t know the original tunes) and reducing pointers to notes instead of having them occupy an inch of vertical space.
The starting point of the book is – where are XP results? Apparently the C3 project which was the springboard for the XP methodology was a blatant failure, so much that no one in Chrysler want to hear again of XP. C3 not only failed to hit the milestone (replacing the legacy payroll system before any chance of y2k bugs to manifest), but failed to produce a working system. According to the evidences that can be collected on internet and books, before being cancelled, C3 was able to handle only some 10% of the payroll it should have handled.
Nontheless many XP supporters advocate that this was a success, and that a project cancelled is not a failure, it’s just that the project stops to deliver value to its customer. XP propose other odd claims, such as, the planning doesn’t exist per se and XP project contracts should feature an ‘optional scope’. The customer should sign for a fixed amount of money and time, but it is not granted to have a result.
The book authors propose a fitting metaphore, they state that XP practices are like a circle of snakes. The XP requires a great effort to keep snakes at their places without anyone being harmed, but at the first distraction or relaxation, the snakes unravel biting the bystanders.
Some practices are identified as being more hard to follow closely. Also some roles have too much responsibilities such as the on-site customer (she is supposed to code unit test) and the coach (who is the warden of the XP verb, costantly taking care no one drift away from hortodoxy).
Also some risk are identified in the real world implementation of XP – likely a superficial management/customer would like the lack of up-front design and documentation, because this means that the programmers will start early to deliver something. But it is also likely that the very same superficial management would not apply unit test and costant refactor. In these situations all the XP methodology crumbles on itself. Many programmers had written to the book authors reporting their, usally bad, experiences in XP projects.
Another fitting observation is that basically what XP is doing is to enter maintenance mode from day 1. By looking at the traditional cost curve for a software project you notice that during this phase the curve is quite flat. And in fact what XP claims is to provide a flat cost curve. But it is the point where the project is most expensive. No one of the XP techniques can do anything to lower this.
Anther point that left me puzzled about XP was… pair programming. According to XP every activity has to performed in pairs. To support this claim Kent is ready to offer some references. XP refactored run a bit of investigation and discovered that the test (yes, just one) supporting that two heads paired have a productivity greater that a non-paired duo, was conducted on college students. Obsiously the results cannot be related to experienced or senior programmers.
The book closes with a refactoring of the XP methodology. I would say this is the least interesting part, since it turns out to be just another methodology not so different by the agile ones proposed in other book of software engineering.
To sum it up, I think you better read this before deciding to enter an XP project, and definitively you MUST read this book before running your own project with XP methodology.