Exultant, the second book in the Destiny's Children series felt a lot better than Coalescent. Not without its own flaws, it made the entire experience better, but maybe that's just me.

The book describes a universe twenty thousand years into the future, when human kind has infested the galaxy, destroying all sentient races they encountered with their immense war machine. They are currently at war with a technologically superior enemy called the Xeelee, which are trapped at the core of the galaxy, pushed back by the sheer size of human forces. The war has waged for 3000 years and continues with no advancement of any kind, with the entire human philosophy focused on spewing more and more cannon fodder for a war that is neither to be won or lost, just endured.

A rather bleak vision of the future, but fear not, there comes hope! Somehow, an excentric aristocrat comes with all the ideas and resources to create the ultimate weapon that will destroy the Xeelee! And in the pages of the book it is described how they go at it. This is where the book actually fails, because at a such immense space and time scale, a solution of this simplicity is just not believable. You don't feel it in your GUT! But the book is well written, the style bringing memories of Asimov, and the ideas in it pretty interesting.

Stephen Baxter is again applying Universal Darwinism to his universe, bringing more and more species and types of lifeforms out of his magician hat. The ending of the book is terribly naive, but without a bit of naivite, you cannot finish great space sagas in a single book.

Bottom line: if you like space fights, military stratagems, character development, time travel, large scale galactic intrigues and a lot of techno babble (and I know I do! :) ) you will love this book. I do think that some of the great ideas in the book would have mixed nicely with late David Feintuch's writing. Anyway, on with the next book in the series: Transcendent

In 1973, Frank Herbert wrote a book called Hellstrom's Hive in which it described a sect of people that lived underground, in a system much alike insects, with individuals specialised for different tasks and all living for the big hive organism. The book did not explain how it all got there, it just quickly described the situation and then delved into the action.

Jump to Stephen Baxter's Coalescent, the first book of the Destiny's Children series, which pretty much details how a group of humans would reach a plausible hive like society. Unfortunately, the book is more descriptive than anything else, failing to deliver in the action part. A lot of characters are developed and a lot of history (both personal and general) is detailed, but in the end the characters vanish as if they never mattered. It is, after all, the whole point of the novel, that ignorant individuals following certain rules lead to the emergence of patterns, but it did not fit well within a book.

Not that the book itself is not fascinating and well written, because it is, but the pace is very slow at the beginning, accelerating to a snail pace in the end, while the different parts of the book seem fractured, too little related to one another. I intend to read the rest of the books in the series, but I might just give up, too.

Bottom line, I think it would be a nice read to start with Coalescent and then read Hellstrom's Hive, although I do think the second book to be much better.

Infected is a typical American sci-fi book, including small town mentality, a sports and US centric view, lots of government agencies, all working for the good of the citizens, keeping them all safe and ignorant and the warped morality that tells people they should destroy before they understand, just because they fear it.

That is something to be expected from an American author, though, and the book itself is not bad. It felt like it was inspired a lot by Stephen King's Dreamcatcher, which featured a similar personal dillema of alien infestation while the gov'ment was on the chase, but that one had more oompf. Of course, you can't compare aspiring Sigler to King, but then again, King's writing was never so great to me to begin with.

What I found really astounding is that a civilisation that uses biological machines to create a beach head on another planet would be so easily thwarted by a college athlete, a trigger happy black ops CIA agent and about a doctor and a half. Oh, and some Apache helicopters. What bothered me to no end is that I also felt this was a plausible scenario. I hope I am just stupidly influenced by similar literature, but would it really help to destroy the enemy before you get to at least understand it? What about the technology that was so easily recognisable as foreign and above Earth's current scientific level?

As a conclusion to both book and my own feelings: it was a nice read; not spectacular, but good enough to keep reading till the end. It is also available in podcast format and I myself have read it from a text file saved from a PDF that was gracefully provided free of charge by mr Sigler on the Escapepod podcast site.

Don't go all "Oh no, not another Beowulf remake!" on me. This is a book that was written in 1971 by John Gardner, presenting the story of Beowulf through the eyes of Grendel. But it is not really the same story, just uses it as a scaffold for the philosophical ideas that he wanted to expose.


Structured into 12 chapters - each for a year in Grendel's life, each for a description of a philosophical current, each for an astrological sign - the book is not an easy one to understand, albeit pretty short. The language is modern and the wording is clear, but the underlying ideas need time and brain power to process, so don't read it in short bursts when you feel bored. Give it what it needs.

In the book, Grendel is not an animal monster, a thing with no thinking, quite the opposite. He is intelligent, articulate, philosophical, all these qualities being given to him at birth, not as a merit to anyone. He is hopelessly depressed and malevolent. He sees life and existence as meaningless, all the Universe a hollow illusion, a thing set to hurt him, set him apart, mock him. It is really easy to identify with him and to feel his feelings, while in the same time despise what he does and why he does it. Grendel is the part of us which we hate and which hates itself.

Enough, though, the book has bad parts as well. The occasional poem lyrics are meaningless in this book. The ending is confused and confusing. I would have liked a clearer ending, that's for sure. And also, it is hard to understand the book without at least knowing the Beowulf story and researching a bit from the Wikipedia article to find out what are the philosophical references hidden in each chapter. But then again, it was never a simple book, and the research (even if I haven't found time to do it) is worth it.

There was an animation film made in Australia in 1981 and featuring Peter Ustinov called Grendel Grendel Grendel which was based on the book, although I haven't been able to get my hands on it. It was partly musical as well, as expected in such a period, ugh!

If you are interested in finding out more about the meanings in the book and discussing about it, here is a link: The Grendel Board.

Finally, another book finished. It is not that I am illiterate, really, but lately I have been listening to podcasts every single free minute. I even fall asleep like that sometimes.

Anyway, this book is rather well written and gives some interesting insights into the Microsoft "puzzle" hiring interviews, revealing as well the highly competitive culture behind the system, as well as the most obvious flaws. One of the most famous such puzzles is in the very title of the book. The interviewer would ask one how would they move mount Fuji. The expected answer is a detailed analysis of the process and the more situations and data the candidate thinks of, the better. Of course, there are really stupid puzzles as well, used only to assess how the prospective employee reacts under stress. Others are deceptively simple, but hard to guess.

I will give you one. Please think about it as long as it takes to be CERTAIN the response is right. In fact, I won't even give you the answer. Here it goes:

You have four cards on the table. Each card has a digit on a side and a capital letter on the other. As placed on the table you see the cards like this:

The request of the puzzle is this: what cards must be turned in order to verify that the four cards on the table verify the rule "Every card with a vowel has an even number on the other side". You need to give the exact cards not the number of cards and (of course) turn only the ones that you need, so as little card turning as possible.

Science-fiction author Arthur C. Clarke is one of the people that has defined me as a person and who's books provided both comfort and excitement during my childhood and adolescence. He is mostly known for the movie adaptation of 2001: A Space Odyssey although I liked the Rama series more. He also invented the concept of a geo synchronous satellite. 
He has lived a full life and I don't believe in artificially prolonging living above a certain threshold (he was suffering for 13 years now), so I am just happy to have known about him rather than sad for his death.

More details at this BBC News article and this Wikipedia entry.

In my own quest to find interesting books that would help me understand my place as a software developer I've stumbled upon Dreaming in Code, something I knew nothing about other than it featured the word "code" in the title. It had to be good!

In the end the book surpassed my expectations by describing software from a totally different point of view than the programming books I am used to. Dreaming in Code is not a technical book. It can be read by software developers and bored housewives alike. It features a kind and professional tone and the three years of documenting the book can only help put the whole story in perspective.

The storyline is simple: a software visionary decides to start a new project, one that would be open source, innovative and revolutionary and also a replacement for slumbering Outlook and Exchange type of software. Scott Rosenberg documents the development process, trying to figure out the answer to the decades long question: why is software hard? What starts very ambitious, with no financial or time contraints, ends up taking more than three years to get to a reasonable 0.6 release, time when the book ends. The project is still ongoing. They make a lot of mistakes and change their design a lot, but they keep at it, trying to learn from errors and adapt to a constantly changing world.

For me that is both a source of inspiration and concern. If Americans with a long history of software spend millions of dollars and years to create a software that might just as well not work, what chance do I stand trying to figure out the same questions? On the other hand the spirit of the team is inspirational, they look like a bunch of heroes battling the boring and pointless world of software development I am used to. And of course, there is the little smugness "Hey, I would have done this better. Give a million dollars to a Romanian and he will build you anything within a month". The problem, of course, is when you try to hire two Romanians! :)

Anyway, I loved this book. It ended before it had any chance of getting boring, it detailed the quest of the developers while in the same time putting everything in the context of great software thinkers and innovators and explaining the origin and motivation behind the most common and taken for granted technologies and IT ideas. It is a must read for devs, IT managers and even people that try to understand programmers, like their wives.

Here are some links:
Official book site
Scott Rosenberg's own blog
The official site of the Chandler software project

This book is a short and easy read and it describes the way the web will change the world in Hamilton's vision. Part of the Web series it tells the story of a quest of online friends in the Realworld. At the end both virtual and real worlds mingle in an interesting way. A nice read from Hamilton, a quick pocket book relaxing read.

I wondered about this book, since it had Hamilton's later style combined with a nearly marginal subject. Also, Misspent Youth has the title Magic Memories on my PDA. But the bottom line is that this is the story of the beginning of the rejuvenation technology, heavily featured in the Pandora/Void universe, but with other details that link it to Night's Dawn. However, if you completely ignore this science fiction limbo status and the few social issues that Peter F. Hamilton raises in the book, the story is no more than a soap!

I mean you have it all: young upper class people interchanging partners like they're researching combinatorics, puppy romance broken by experienced charmer, broken homes, even parent and son on opposite political sides. For someone that has read the more monumental scifi from the writer, this is like a break from the science fiction of it and towards a more personal point of view. For someone else, it may feel simply mediocre.

My conclusion: even if the book is well written, it is plagued by a the lack of a proper subject, the positive outcome of every single thing (remember Fallen Dragon? I said I can't possibly relate with the passive philosophy of the main character there, same here) and the quick, undetalied ending that one can observe also in the Commonwealth Saga.

This is not a single story, but many short ones from my latest favourite writer: Peter F. Hamilton. A Second Chance at Eden is set in the Night's Dawn universe, but before that story unfolded. We have Marcus Calvert, father of Joshua, the hero of Night's Dawn; we have the birth of Eden, affinity bondage stories, zero-tau, psychic abilities, even a party assassin turned good (that would provide the template for a character in Pandora's Star).

I think that the collection is best read after you've read the lengthy stories. It rings so many bells that would normally not mean anything than sci fi speculation otherwise.

Bottom line: Great writing from Hamilton. It's nice that you can read one story and take a break and do something else :). I guess if you are not that sure you want to read the sagas, starting with this will open your appetite and you will find the same connections I did, only backwards.

Something happened to Peter F. Hamilton between the second and third volumes of the Greg Mandel trilogy. He turned from a good average writing style to a great one. The Nano Flower is almost at the same level as Pandora's Star and births Hamilton's detailed universe. No wonder there was no fourth novel in the series, it would only drag the writer down.

The book has everything I came to expect from Peter F. Hamilton: hard sci-fi, detailed socio-political context, aliens, the party of braves, the sociopathic villains, a reference to Lord of the Rings... I do believe that Tolkien inspired Hamilton to write, but now it has become the chink in the writing armour, Achilles' heal. I've read a few great Hamilton books, but each had the basic layout of a battle between good and evil, groups of people uniting under improbable ideals to defeat an all too dark a villain. The qualities that attracted so many people to Lord of the Rings, for example, like camaraderie, honor, desire to help others, are not so attractive to me anymore. They are basic, very unlikely to truly define a character. I would very much want to see a Hamilton gray book. Maybe the new Void Trilogy will fulfil my wish (if I don't die of waiting for it to appear), although the vengeance driven character that remains pure and good at heart described in the first volume doesn't give me a lot of hope.

Anyway, even if I do seem to concentrate on what I don't like or what I would change in the writing of this great book maker, my appreciation for him is way higher than any possible defect in his writing. So, if you don't totally dislike sci-fi, go to a book store and buy Peter F. Hamilton books.

• I have started with a book recommended by many sites about software architecture and design as a must read: Smalltalk Best Practice Patterns by Kent Beck. It is well written and I can see why it attracted a lot of people, even if there aren't so many Smalltalk programmers out there: it is written for use! That means that the book has less than 200 pages, but each of the specific patterns there are laden with references to others in the book, some even in the next chapters. That's because the book itself is structured to be kept nearby and consulted whenever a new project is started or in progress, not something that you read and forget in a bookshelf, gathering dust.
  
  However, the patterns presented are sometimes useless for a C# programmer, some being already integrated in language and some being not applicable. The fact that Smalltalk works with Messages further complicates things. I did eventually open a link to #-Smalltalk, but who will ever have time for it?
  
  I have decided that rather than reading this book and forgetting or not getting many of the things inside, it would be more efficient searching for a similar book that is more C# oriented.
  
  So, bottom line: great approach, both literary and technical, but a little hard to use for one such as me. Anyone know of a C# Best Practice Patterns book?
• My next attempt was in the wonderful world of management! Yes, I was approached by their people, apparently they want me to join them and rule the galaxy. Maybe if they wrote more concise books!!
  
  
  The Knowledge Management Toolkit: Practical Techniques for Building a Knowledge Management System starts interestingly enough, describing the need of every company to build a way to retain knowledge against employee turnover or plain forgetfulness. Basically what I am doing with this blog. But it goes further than that, quantifying the return on investment for such a KM system, describing ways of rewarding people and encouraging them to use it (it is not something done automatically).
  
  All great, but then it kept going on telling me how the book is going to change my world, rock my boat, help me in my business... after reading the preface, the introduction, the "how it's structured", the marketing bullshit, the first chapter (full of promises about the next chapters) I was completely bored! If there is any technical description of what to do, when to do it, how to do it, why , etc, I didn't find a trace of it in the first chapter. Reading on my PDA from a badly scanned txt file didn't help either.
  
  Besides, I got more and more frustrated. I barely have the time to scratch all I planned on doing in this holiday (while getting nagged on by the wife, the cat and whatever friends I got left) and improving the company workings is not my responsibility. I am the god damn coder! I write code! I have a management system all of my own and I get my ROI by googling a frustrating bug and discovering I solved it a month ago myself and wrote about it here.
  
  So there! If you have a business it is good to have a repository of actual knowledge (a.k.a. processed information) and encourage people to use it so that they don't take all their experience with them when they leave your sorry cheap ass company! I've summarised the entire book for you! I am not reading it anymore. It hurts my sensitive techie soul!

A Quantum Murder comes to continue the story of Greg Mandel, psychic detective. Does it sound tacky? I agree that the subject is not the best possible choice, but the writing is good, Hamilton style: scifi social speculation, action, a detective story that makes the reader wonder what will happen next and whodunit!

I personally did enjoy the book, but it wasn't even close to the latest and more hard scifi writings of Peter Hamilton's. Maybe it's just me, but mental detectives in a post apocalyptic corporate world just doesn't do it for me. Maybe that's why The Nano Flower's first chapter starts with Suzi doing tekmerk stuff ;)

Again, the second volume of the three Mindstar books is stand-alone, making it easy to read even if you didn't read the first book. It is basically a scifi policier.

Another great book from Hamilton! This is part of the "Greg Mandel trilogy", that meaning there are three books to show for this particular side of the Hamilton universe, and unlike his later work, Mindstar Rising is actually a stand-alone book. You can read it without its next two parts and understand it as a single story. I've even started to read A Quantum Murder (volume 2) and Hamilton is making the effort to summarize what the characters did in the previous volume.

I understand the dilemma facing such a prolific writer: should one break a story in stand alone segments, thus cauterizing story arches and trying to put every single idea into single puny volumes? Should one bore the readers with summaries of previous volumes? Or should one write huge three volume books that you need to read in their entirety to understand anything? :) It would be a hard choice for me, as well. All I can say is that I enjoyed the big stories as well as the more common way of writing one book stories and reminding the reader of previous stories. I highly recommend the Seafort Saga for this particular style, even if it grows old by the eighth volume. Consider it, though, I was attracted to the story by accidentally reading volume 3 and understanding all of it!

Anyway, back to the book that I was reviewing, damn it! Mindstar Rising describes a post apocalyptic Earth, where global warming and subsequent social and economic disasters brought civilization to the brink of dissolution. A psychic ex-military, now working as a private eye is asked to help in finding the source of industrial sabotage and from then on it just gets more complex and thrilling. I wouldn't say that this is one of Hamilton's better books, though. Even if the book is definitely fun to read, it pales in comparison with Night's Dawn or the Commonwealth Saga. It is more like Fallen Dragon in style, although I do hope it doesn't end in the same ridiculous way.

More to come as I read the next two books.

This book started great. It outlaid a structured view of how a software company should function, from the way one designs projects, to code and documentation standards. I really hoped this was the mother load: a book that would show me how a "standard" IT company functions on every level. It wasn't. Mark Horner started it well and ended it badly. A shorter book and more to the point would have been enough.

Bottom line, the book starts in an interesting way, describing what I would call "IT gap analysis", in other words the application of a simple idea: begin with a detailed (and documented) picture of what the current (start) situation is, then describe just as much detail the situation you want to reach (end). From then on, the job of describing the transition becomes orders of magnitude easier. That applies to software projects (start with what the client has and needs, then create the plan to bridge the gap), documentation (start with the functional and end with the structural) and ultimately code (start with abstract classes and interfaces, then fill in the missing code).

Other than that there are some (hopefully) nice references, then a lot of empty space filled up with irrelevant things: description of design patterns (which are nice, but there are books for something like this), a glossary of terms (some were never even used in the book!) and then the general way of describing something, then adding the "Standard acknowledges" part that basically says the same thing as his own description. It generally felt as a student paper from one that needed only a passing grade.

Sorry Mark, better luck next time. I will add here a short summary of what yours truly thought was noteworthy in the book:

• use gap analysis for all the levels of your software work. When you define what you have and what you need, filling the blanks becomes easier.
• use functional documentation, design documentation and structural documentation to detail what you wanted the software to do, how you designed to solve the problems and what are the basic building blocks of the project (classes, patterns, etc).
• use code standards and peer reviews and even external code auditing to improve the quality of code. Refactoring is a must. Popular code development methodologies include Extreme Programming and Rational Unified Process.
• use a design standard like the open-source architecture framework (TOGAF)
• the enterprise vs. domain dichotomy. Should a software be started from scratch and done for the current set of requests only, or should it be designed as a general component ready for reuse? I would really go towards the enterprise, even when the profit from the extra work is not immediately obvious. Sometimes things that you have prepared in advance and nobody acknowledged become a real time (and life) saver when unreasonable requests tumble down upon you.
• also linked to the enterprise/domain issue: an application framework solution. Create a basic Visual Studio solution that contains common components used in many projects and use it as a startup solution.
• use the Visual Studio formatting options to keep your code well formatted. Use a standard of naming variables, methods, properties. My own choice is using lowerCamelCase for inner variables, prefixing the name with an underscore for fields. UpperCamelCase (or Pascal) for methods, properties and class names. Hungarian notation for controls (lbName for a label with a name). I don't really care if one names the control txtName, tbName or tboxName, as long as the prefix is revealing.
• use the Obsolete attribute for methods and properties that are intended to be removed in the near future. In my own library I have used methods that became obsolete with the coming of .NET 2.0 and used this attribute to point not only to the obsolescence, but also to the blog entry detailing the reasoning behind it.
• this is basically derived from other sources, but I do think it is relevant: best practices recommends using composition over inheritance, wherever possible. I admit that the coding of composition is much more complex, but with the refactoring tools found in Visual Studio and its add-ons (like my beloved Resharper), it becomes similar in complexity.
• references:
  
  1. book: Programming C# by Jesse Liberty, published by O'Reilly
  2. dude: Martin Fowler is a leading authority on refactoring
  3. books to understand object-oriented development: Object-Oriented Analysis and Design with Applications by Grady Booch, published by Addison-Wesley in 1994
  4. Expert C# Business Objects by Rockford Lhotka, published by Apress in 2003
  5. book: Code Complete, by Steve McConnell, published by Microsoft Press 2004
  6. authorities on design patterns: Martin Fowler, Gregor Hohpe, Bobby Woolf
  7. dude: professor Trygve Reenskaug and his discussion on the role of object collaboration: Role Modeling and UML-VM discussions

My conclusion: read my summary and you don't waste two days of reading time.