Il Mistero della Sibilla Appenninica

“Il tuo codice è scritto bene, raffinato, solido ed evoluto, tutti dovrebbero scrivere codice così, ma gli altri hanno difficoltà a capirlo e sarebbe meglio che tu abbassassi un po’ il tuo livello così che sia più semplice per loro capirlo e modificarlo”. Questo, parafrasato, è quello che ho sentito in un paio di esperienze lavorative. La mia reazione, scoramento a parte, era che in realtà avrei ben volentieri aiutato tutto il team a crescere piuttosto che abbassare il livello.
Questo è un po’ il mio parallelo conclusivo de “Il Cacciatore di Sibille”, ma andiamo con ordine.
È la prima volta che mi capita di recensire (e leggere) un libro scritto da un mio amico.
Ho conosciuto Michele a Perugia in pieni anni 80. Condividevamo la passione per la programmazione (con lo Zx Spectrum) e la fantascienza.
Ci siamo persi di vista dopo i miei trasferimenti e la mia pigrizia epistolare.
Grazie a Facebook ho letto della sua attività di scrittore e del suo primo (credo) libro e d’impulso ho acquistato una copia in formato Kindle. A proposito, ottima idea quella di utilizzare questo canale di distribuzione.
Scrivere qualcosa mi è piuttosto difficile perché “il cacciatore di Sibille” è un libro molto diverso e lontano dalle mie abituali letture. Quando non leggo testi tecnici in inglese, i miei gusti sono orientati alla fantascienza e al fantastico. Mi piacciono i libri di azione, mistero, intrigo che abbiano comunque una trama solida (non tipo Dan Brown per intenderci).
Il libro che ho appena finito è un libro ricercato, raffinato, dove ogni parola, ogni aggettivo, ogni periodo è ricercato e calibrato. Dove intenzionalmente la lettura è impegnativa: aggettivi desueti (10 punti per l’uso di “onusto” e “ctonio” sicuramente una delle poche, se non l’unica parola dell’italica favella, che contenga la sequenza ‘ct’). Dopo averlo letto mi sento un po’ come un estimatore dei fast food reduce da una cena di novelle cuisine.
Il mio problema con il libro è probabilmente legato ai miei limiti di lettore. Nei primi quattro quinti del racconto non succede molto. La storia della Sibilla appenninica viene presentata attraverso tutti i vari personaggi storici che ne hanno parlato nei loro racconti. Il libro è scritto curiosamente in prima persona, ma il protagonista rimane indefinito. Non sono riuscito a cogliere alcuna motivazione più o meno profonda che spingesse il narratore in questa impegnativa e sofferta ricerca, né cosa gli facesse cambiare idea in merito all’oggetto delle sue ricerche nel corso della narrazione. Perfino l’occupazione del protagonista rimane misteriosa.
Un altro aspetto che mi suscita qualche perplessità è che molte svolte importanti nella ricerca avvengono più o meno per caso. Sfogliando una guida turistica o un tomo in una libreria… come se l’attività di ricerca fosse solo documentativa e i veri avanzamenti nella conoscenza del mistero fossero casualità (adesso che l’ho scritto mi viene da pensare che spesso è proprio quello che avviene in realtà).
(Nel prossimo paragrafo parlo della fine del libro, il che potrebbe rovinare il piacere della scoperta a chi non l’ha ancora letto).
Ultimo punto di alzamento sopracciliare riguarda la conclusione. Ribadisco che anche questo è probabilmente conseguenza della mia insana dieta letteraria. Alla fine arriva il tanto sofferto incontro con la Sibilla, a il protagonista non trova niente di meglio che scappare. Cioè per pagine e pagine si prepara l’ineluttabilità di questo incontro nefasto, blasfemo, illuminante… e poi non succede nulla. Anche la torcia del nostro che sembrava essersi spenta per arcano potere magico viene riaccesa semplicemente come se nulla di soprannaturale fosse intervenuto.
Il mio spirito di “consumatore” di letteratura fast food un po’ rimane deluso più che altro dall’occasione persa: ci sono tutti gli elementi per un grande romanzo di mistero, azione ed intrigo. Cambiando registro e aggiungendo qualche ingrediente più dinamico, questo libro avrebbe potuto raggiungere una popolarità molto maggiore.
Vorrei però che di questa mia recensione rimanesse soprattutto questa nota positiva: Il cacciatore di Sibille è un grande libro. Lo dico convinto, non per piaggeria. È uno scritto erudito, complesso, scritto con una reverenza ed una cura per la lingua italiana quasi religiose. Volendo banalizzare è come un libro di Eco riscritto da un accademico della crusca. Questa sua eccellenza è al tempo stesso il suo limite: non è un libro per tutti.

Agile Estimation and Plannning

Agile methodologies yield appealing promises – deliver the maximum value for customer money by frequently releasing a shippable version of the software kept in sync with the customer’s needs by the presence of a customer proxy in the development team.
I hadn’t really bought in all the hype of agile, but I think that there are a bunch of principles that make a lot of sense. Unit testing and make the simplest working solution are the first two that come to mind. Beside that I was very curious about how the agile deals with planning.
In fact, though agile preaches not investing on documentation and does not make any warranty about reaching any given feature set in a given time, agile uses estimation to size iteration time span and move one to the next. The same estimation is also used to assess the “speed” of the team and as such forms the base for next estimations.
In XP you have the so called “planning game”, where programmers confront each others bidding for features (“I can do this in 3 days”, “I can do it in 2” and so on).
“Agile Estimation and Planning” is a very good book, it presents the matter in a smooth way, with many examples, but not too much. It doesn’t tackle a specific process, but illustrates a way to estimate and plan that is compatible with the agile practice.
Such compatibility is also a limit. In fact, in order to have the agile working, you need to find a suitable context. One where everyone is willing to accept that at the end of the budget there won’t be what we agree on today, but (if everything goes fine) the best value for the money spent. Let’s say that if you find such a context of trust and understanding, then it is likely that any methodology will work. But I am digressing.
Nonetheless Mike Cohn manages to provide how-to guide for the cases for the rest of us, i.e. when the customer wants something for a given date and in a given budget. The method described accounts for evaluation of worst case and some statistical mumbo-jumbo to get a number that is less than the sum of the global worst case. That makes sense, though I didn’t find in the book any mathematical support for his method. Well this doesn’t mean that the method has no mathematical ground, just that it is presented as something “given” rather than derived.
Overall the book is a pleasant and inspiring reading regardless you are on an agile project or not. I recommend it to anyone who is required to estimate software development task.

The Practical Guide to Defect Prevention

If you happen to be involved in software development you know how much it costs and you can’t ignore the chances of reducing defect count and thus increasing the cost-effectiveness of the process. So I started reading this book with much interest also because the word “Practical” in the title looked very promising.
I had some trouble to get over the slightly disturbing detail that a book on defect prevention has been written draining experience and making examples from the development of the Microsoft Windows Vista. Despite of this, the book is very well detailed and offers indeed practical approach, though “practical” does not imply that you can easily apply in your working context.
In my workplace software development barely reaches level 2 of CMM and the main management idea is that software development should cost no money and give results by yesterday. In this context (that I feel is not so infrequent) I find quite hard to ask for simulation software or defect classification software when they cost several thousands bucks.
Anyway the overall structure of the book is good in teaching what is the state of the art in preventing software defects, but basically it sums up to go up in the CMM level.
Some points in the book made me raise my eyebrow more than once. For example when praising the qualities of code review the author states that the best time to peer review the code is as soon as it is written, even before it is run through the compiler. The reason is that in this way the maximum number of error is caught by the process. That’s puzzling because a great deal of the same errors may be caught automatically by the compiler itself. So, though the number of detected errors is high, the advantage in doing so seems IMHO quite reduced.
Nonetheless I think this is a good read worth reading, even if most of us fellow programmers won’t see any of those techniques in they everyday software development (I’m not talking with you working at NASA ;-)).

Does God Play Dice? The New Mathematics of Chaos

What if you discover that what you know about math physic is wrong? That would be quite a surprise, but it is what actually is if you haven’t studied chaos theory.In fact I felt quite surprised when I read this book by Ian Steward. Surprised and Enlightened. The book is an educational essay on the math physic history and the most recent advances on the so-called theory of chaos.
Basically the core concept is that the classic equations describing system motions have been developed in the 17th century properly describes only ideal cases. It was thought that the real world effects, being small could be considered negligible.
What the real world insistently taught us in these years is that those small contribution can not be ignored for given enough time they will sum up and will turn you neat and smooth equations into the negligible part. The worst part is that for most system, even after a short time the system becomes unpredictable.
The author is a university professor and does a great job in presenting the matter, there are few equations, but they are thoroughly explained. Still with my aging university math (I studied analysis in 1988) I found I could follow easily the topic.
This book is fascinating under many aspects – historical and philosophical. I also found very enlightening some ideas. For example everyone knows the so-called butterfly effect – a butterfly flaps her wings in Tokio and your weather forecast on the East Coast are totally messed up. Now I always thought about this effect as an annoyance in getting the right weather forecast. But correctly you may see on the other side – it is an amazing mean of control. With so little energy you may control huge phenomena.
I also loved the part at the end of the book where Steward defends mathematicians against the popular belief they are closed in their Ivory Towers without doing anything useful. As he – correctly – points out, they are doing their work (as anyone else on the World) and their work usually has useful applications in everyday life even though they could not happen immediately.
(Italian title: “Dio gioca a dadi? La nuova matematica del Caos”)

Reading a quick summary – part 2

Robert Glass Software Creativity 2.0.
Quite an interesting reading. The author attempts to answer the recurring question whether writing software be a procedural task or a creative process. The question is very interesting and it is at the core of software engineering practices. If the answer is the first, then writing code can be automatized and programmers may be considered interchangeable. The topic is difficult and the author attempts to follow a pragmatic if not formal approach to give the answer. I liked the answer (yes it is a creative process, sorry to spoil, but I couldn’t resist), but I find the book somewhat weak in giving short and fit references to help programmers in dealing with management to get their points… not that management would care anyway.
James W. Grenning Test-Driven Development for Embedded System.
Firmware development tends to be one of those niche where the “NAH” (Not Applicable Here) defense is used for preventing proper software practices to be applied. Structured, Hardware independent, Object Oriented… in many circles are considered techniques unsuitable for embedded software. I am pretty convinced of the contrary, and this book really is a valuable allies. The book is about test driven development (that is, first write tests, then code) which is another “heresy” for bare metal programmers. I found very well presented, although sometimes a bit verbose (if you are an experienced programmer you may find yourself often skipping through some examples). If you are curious about unit test, and how to apply it to firmware then this book is a must read.
What you won’t find is how to unit test interrupt depending code (i.e. critical run and critical sections) and how to test multithreading code.
Umberto Eco Il Cimitero di Praga (The Cemetery of Prague).
I enjoyed reading Eco in the past (“Baudolino” and “Il pendolo di Focault“, “In nome della rosa“) although I found his book having two speeds – the first for the first half of the book quite modernly paced, the second, slow and hyper-detailed for the rest of the book. I had the impression the writer was more devoted in showing the result of his culture and his researches rather than telling the story. This is true to a lesser extent for this one.
The story is intriguing and I felt really at discomfort to read in first person the actions and the motivation of the main character (a late 1800 forger involved with European country intelligences) a selfish racist that has no hesitation in faking friendship and then killing those who trusted him. Nonetheless the book given big bytes of food for thoughts both about recent history and how intelligence works.
Alexander Stepanov, Paul McJones Elements of Programming.
The title is a clear declaration of intent – this is a text book, in the same shelf where you would look for elements of mathematical analysis, elements of algebra and so on. The book follows strictly the cliche, feeding theorems and lemmas to the reader. So it is not a light reading. By reading this book I finally discovered an application for those strangely named algebraic structures (Ring, Semi-Ring and so on). Basically when dealing with generic programming you need some mathematical tools to request the shape of the data types on which you may (or may not) instantiate the generic algorithm. The book is mostly about answering in a formal way to this need. Do you need to read this? I am quite doubtful, if you want to learn programming, this is not the book for you. If you are fluent with template metaprogramming, I guess you won’t find much for you in this book. If you are studying the theoretical connection between mathematics/algebra and meta programming, then maybe this is what you are looking for.

PHP In Action

Being a fair programmer may not always be enough to be a fair web programmer. Web programming has some peculiarities on its own. Defining a sound architecture for a web site is all but a straightforward task. This may explain why the software I wrote for this blog has grown a bit out of control O:-) (and, put it in this way, allows my ego to be safe).That’s why I looked for a book to improve my PHP web programming and found “PHP in Action”.
The book is packed with pleasant surprises. First of all it is a darn good book on web programming. Author spends a good time in explaining scenarios and examining programming patterns in easy-to-complex order able to solve the related problems.
But the book is a really good book on design in general. Several patterns are described in a hands-on, no-nonsense approach. More are introduced when dealing with specific aspects of web programming. A brief introduction to object oriented programming is included as well.
I found very valuable the presentation on Unit Test and the arguments for Test Driven Design, so much that I promptly searched a unit test library suitable for C and C++, so that I could use the same approach on my daily job.
If you are interested in PHP programming for Web I highly recommend this book.

The Last Hero

This is the first illustrated Terry Pratchett’s novel that I read. According to the legend, the first Hero stole the fire from gods. Now the Silver Horde – a bunch of elderly, but nonetheless lethal, heroes – is committed to bring back the fire to gods with interests – the Discworld equivalent of an atomic bomb. Unfortunately the detonation on the god citadel would cause the dispersion of all the magic bringing Discworld to death.
All the discworld nations ask Ank-Morpork to save the world. So the patrician assigns this mission to Captain Carrot, Rincewind the Wizard and the inventor Leonard of Quirm.
I found Rincewind and Leonard very fit in their part, while I had more surprise with the parts played by Carrot and by the Patrician. I can’t imagine capt Carrot joining the terror hymn that goes like “Aaaaaarrrrrggggghhhhh”. Carrot character has always given the impression of blind faith in the system. Thus he should have a wonderful faith in what the system has produced to save the world. The patrician is a fine connoisseur of human minds, I feel uneasy when he fails to understand Ponder Stibbons. Also very far of the image I have of this character that he propose so plainly to kill the Librarian to save the mission. The patrician is subtle, manipulating, not plain, nor direct. And the story, at a given point, cites a B plan, that is very Patrician, but the topic is not evolved… it seems more of a device to talk briefly about the attempt of ecumenism on Discworld. Also Death, who usually is very attentive to the fate of Discworld was a bit lacking, he just takes a look at the hourglass of the giant A’Tuine (the turtle that floats in the space void carrying four elephants that, in turn, carry the Discworld.
So… this is not one of the best book by Terry Pratchett – it is better than Erik, but worse of the other books. Nonetheless the drawings are gorgeous and the story is entertaining.

Slack

I hate wasting time. If you have time don’t wait for (more) time, that’s one of my favorite savings.When I started working I had a small commute by car and some time got wasted waiting for the traffic light to become green. So I started reading books in those waits.
With my MS-Windows becoming slower and slower at startup, I decided to spend the waiting time reading books. At work I started a copy of “Slack” by Tom De Marco. Being a book on efficiency I found fitting to read it in recycled time.
If you work in software development (or if you are a “white collar” at large) you ought know who Tom De Marco is. Or, at least, you should have heard about the book he wrote with Timothy Lister – Peopleware. This is one of the most referenced book, almost every book on project management written in recent years quotes Peopleware.
Back to Slack, this is a book intended to be read in a short time to convey good an bad practice about efficiency, innovation and risk taking in today’s organizations.
The author states about an hour and half as reading time, I guess it is somewhat more even if you read from page 1 to the end at the same time (and not scattered over a couple of month of PC boots), nonetheless the thought-provoking stuff is very dense. Chapter are short and almost everyone made me think.
It is possible I will write a resume of it in the future, but I strongly encourage you to read by yourself.
Tom hacks through myths trying to grasp what is needed by an organization to survive in times of change and crisis. First myth to fall is the one of total efficiency. Total efficiency means total rigidity. An organization that maximizes efficiency cannot withstand change because lacks of the buffer and the spaces to react to change and adapt.
Then he digs through the (wrong) assumptions about making the organization more productive – pressure, competition, fear and so on.
Eventually he bashes the Management By Objects and illustrates what really means to deal with risk.
For example planning should be an estimation and as a such should offer a range defined by: cannot complete before X and surely completed after Z, with a best estimation at Y, with X <= Y <= Z. Now that’s a planning, that’s quite different by setting a goal. From my experience, someone defines a planning, someone else carves it in stone and says that’s the goal. This way of operation ignores the risk, ignores that an estimation is just an estimation, not a commitment, and it is just a sure way to have a delay on the completion. In fact, even if the most likely date (Y in the example above) is taken, this is usually achievable only with a probability of 33%.
De Marco also marks “Management by Objectives” (MBO) as “don’t”. I already read about criticisms at MBO, but more about the bonus system rather than objectives by themselves. De Marco states that it is hard, if not impossible, that the defined objectives for employees lead the organization toward company objectives. Also in a time of changes it is hard to hit an objective even if the actions taken are excellent for the company.
I found this particular opinion a little forced on software development. I think that an objective and bonus scheme over the course of a project, if properly done, could be helpful. Maybe MBO is just crap if applied to vending or other areas.
I liked the book a lot and I think it is not just for managers (regardless of their level). The more widespread the ideas here contained the better the life of fellow programmers.

The Ultimate Guide to Videogame Writing and Design

Video gaming is for sure one of the reasons I got so addicted in computer programming. Being forced out of the videogame industry in 2004 had not been an happy experience at all and I am still trying to make sense out of it. But life goes on and if I am not really capable of “letting go” that part of my life, I am gardening the (possibly false) hope of making some games in my spare time.I am just a programmer and I know my game design skills will never rival with even to the scantest game designer. That’s why I bought and read this book. Not with the intent of becoming a game designer, rather with the desire of filling some of the gap and better understand the techniques and the mechanics of their work.
The book is easy to read and concepts are easily grasped. I found some little inspiring pearls. The first is the introduction itself. Authors claim that in an ideal world they would have suspended their work for at least one year in order to properly write the book. Actually this is impossible, as is impossible to do with much of the work they do – multiple projects are developed in parallel and the successful worker has to deal with this rather than complaining.
The first drawback is, IMO, a direct consequence of this – the book is not very well organized. I found that some chapters are out of order and oftentimes an overall picture is missing. It is not too bad, you may argue that is just “creative” at work.
Another interesting concept is that writing a game (o a show, a movie) is not “art” but “craft”. I.e. “art” is about inspiration and cannot be relied on for day-to-day work. “Craft” is something that gets thing done, in the best way, even when your muse is on vacation.
The book propose a good number of exercises. I started with the intention of doing them all, but some of them are too time consuming to be done on holiday, with an inviting sea in front of you (and your children yelling around).
The other big drawback is that this book is much more about “writing” than “designing”. The distinction may be thin, but “writing” pertains to the story, while “designing” pertains to the mechanics of the game. Most of (if not all) the problems are seen from the story point of view. Therefore characters are examines and created starting from their story, their internal struggle, their relationship, i.e. everything that is story, rather than from “powers” and which “actions” they perform.
This is not bad per se, it is just that the title may result a little misleading.
I have mixed feeling about suggestions given in the book about the job at large. At one extreme are good advises about how to deal with conflict in the team or with other project stakeholders (even if not everything is applicable in working context other US). At the other end are obvious suggestion (don’t live over your possibilities and subscribe a pension fund).
The book proposes a set of templates for the definition of characters, parties and world. The approach is good and likely the tables contain the right set of questions. In fact I found myself to develop an unexpected and quite awesome background for the videogame I am working at.
To sum it up, read this book if you are interested at story in videogame.

On The Edge

As far as it may seem odd nowadays, there was a time when BASIC was The Language. Computers from different vendors were 100% not-compatible and resources were so constrained that your average mobile phone could be considered a supercomputer when compared to. It was the Home Computer Era. Back then, it was the first half of the 80s, home computers started to spread around even in Italy. I was fourteen and started programming (and playing) with my ZX Spectrum 48k.
We hadn’t Windows or Linux, Vi or Emacs, Java or C#, but we had our religion wars – the most bloody, was Sinclair vs. Commodore and more precisely Spectrum vs. C64.
Owning a Spectrum I was in the Sinclair’s party – the gummy keyboard machine with a nice rainbow. Spectrum had superior BASIC and faster CPU. I like to think I always have an open mind, in fact, some years later, I was about to buy a C64. The Commodore machine sported for sure a superior hardware – more memory, more graphic modes, better audio, sprites, and decent keyboard.

I waited, then evaluated the C128, but bought an Amstrad. Some years later the Amiga arrived and I became a happy Commodore customer.
This book is like a documentary of the troubled history of Commodore. From the very early days, when the designer of the MOS 6502 CPU designed the first PET, to the final days of bankruptcy.
I found the book very good, more balanced of iWoz, maybe just because the writer is not directly involved in the company and just interviews people trying to rebuild facts.
The book reads nearly as a fiction book, with interesting characters, heroes, foes and plot twist, while the narration proceed toward the glooming end.
Two aspects stroke me during the reading – first is about success and failures, the latter is about overtime.
Many of the engineers interviewed hold that the most successful products were achieved when they were free from the marketing and worked almost free (but for the deadlines set directly by the CEO). The most unsuccessful products (notably the Plus 4 and C 16 abominations) were marketing driven. What really strikes me is how could the marketing and the middle management be so computer-unaware? They had a powerful brand, great hardware, yet they failed to steer the company helm to easily reachable success.
Overtime was a sort of way-of-life for Commodore engineers. Unrealistic deadlines were hit thanks to work around the clock for several days. One of the engineers recalls that his longest stay at office was 11 days. He just got some hour sleep in his office.
Unrealistic deadlines were needed to win against the strong competition from other vendors, but this is something you can’t live with for a reasonable time. You have to work less. I am a strong supporter of the 8h/day per 5days a week with just occasional overtime. My argumentation is that overtime tends to burn out people, making them behave in a sub-optimal way in the medium period. Also because of the long hours away from home they need to do something personal at work, just to keep up with life. So I wonder if those jewels (C64 and Amiga) that Commodore gave us could have existed and could have been the same with more human working conditions?