Strict Standards: Non-static method EntryStorage::getStorage() should not be called statically in /web/htdocs/www.maxpagani.org/home/blog.php on line 341
Godspeed Sir Terry
2015-Mar-12 Thursday 21:18 CET
“Why do you go away? So that you can come back. So that you can see the place you came from with new eyes and extra colors. And the people there see you differently, too. Coming back to where you started is not the same as never leaving.”
― Terry Pratchett, A Hat Full of Sky (Discworld, #32)
“I meant," said Ipslore bitterly, "what is there in this world that truly makes living worthwhile?"
Death thought about it.
CATS, he said eventually. CATS ARE NICE.”
― Terry Pratchett, Sourcery
“DON'T THINK OF IT AS DYING, said Death. JUST THINK OF IT AS LEAVING EARLY TO AVOID THE RUSH.”
― Terry Pratchett, Good Omens: The Nice and Accurate Prophecies of Agnes Nutter, Witch
“The whole of life is just like watching a film. Only it's as though you always get in ten minutes after the big picture has started, and no-one will tell you the plot, so you have to work it out all yourself from the clues.”
― Terry Pratchett, Moving Pictures
...and thank you for all your books - all masterpieces.
2015-Feb-04 Wednesday 22:17 CET
In his autobiography - I Am Spock - famous actor Leonard Nimoy wrote that when he started shooting Star Trek he was given a pair of lousy pointy ears props from the production. He found no way to make them look real, nor to stand still on the top of his ears. So he decided to shell out his own money and get some real props.
It is always difficult, when you are passionate about your work, to draw a line to constrain your involvement. In the same way I don't like the precision scale approach - i.e. stopping exactly at my duty edge.
So I decided to overcome some internal bureaucracy problems of my employer and buy a logic state analyzer to do my job. Waiting official channels would have taken a time not compatible with project deadlines.
I opted for a Saleae (the cheapest one - I don't need anything more... and, well, that's still quite some money) and placed an on-line order on Batter Fly. No shipping fees, I got the package in two days... great service (just beware - they show prices on the site without the VAT, surprise is saved for checkout time).
|Here is the box, very light... Suspiciously light, hadn't they bothered to put at least a brick inside?|
|No brick, apparently nothing. But my cat Trilli looks very interested in the chips|
|Here it is.|
|The logic state analyzer is very small. From the picture I've seen I thought it was at least twice the size it actually is|
|In the bag, aside from the logic analyzer itself, there are - connection wires, probes, USB cable and a thank you postcard that doubles as a quick guide.|
The build succeeded... uh, yes, and...
2014-Sep-22 Monday 10:55 CEST
The phone rings in the heart of the night. A sleepy programmer, tired for an extended period of hard work and long hours, wakes up and after a few attempts picks up the receiver. At the other side the slightly frantic voice of his boss: "Good news. The build succeeded.... oh, yes, and Jimmy has been kidnapped".
In fact Jimmy (not the real name), a coworker and friend, had been kidnapped by two crooks while he was withdrawing at an ATM a couple of hours earlier. Luckily he was released in the night, naked in open country, but unharmed.
Well, I wasn't there so I can't say for sure if the conversation really occurred this way or if it has been "enriched" for the audience. But this situation came to mind recently because I start feeling that it captures quite well some peculiar traits of the videogame industry, when compared to software development industry at large.
In my experience, and surfing the internet also to many other experiences as well (see this, this, or this, or just google for more results), most game development projects turn into a nightmarish run for your life against the deadline. The only certainty is that you and your loved ones are going to pay an exaggeratedly high price for you "making games".
Family, health, friends, life, nothing matters when confronted with The Game. You can't plan a vacation with your family, you can't go to the gym, you can't be home to be with your children or your wife, but hooray the build has succeeded.
But why? Why has to be like this in the videogame industry? While industry and academia have developed methods and strategies to improve project management relieving workers, reducing risk and improving quality, why game industry fails so epically to be a saner environment?
Of course every project, regardless of the industry, has to be profitable and economically viable. And the justification I often heard is that if you are late then you can only work longer to hit the target. You have only to agree, but this is just denying the value of planning. Is like to say if you are outdoor and starts raining you can only get wet. Yes. At that point you don't have any other option. But a good planner likes to be prepared and would have brought an umbrella.
As any project management book will tell you, projects are defined by three variables - time, resources, quality. Time is, well calendar time needed to complete the project. Resources are the people working to the project and their tools. Quality is the quality of the product that can also be seen as a list of features.
Of these variables only two can be set, the other one is given. That is, you can set the target quality and the time, but then the resources count is derived and cannot be forced. If you attempt to fix all three variables, then the project will be understaffed or late or shoddy, possibly all three.
Agile process doesn't do any magic, it is just chopping the project into smaller projects with more flexibility on the feature list. A sane agile project will scrap features that don't fit into the iteration and those that add the least value to the project. This is known also as de-scoping and it is something that I found extremely hard to do on a game project planning.
My impression is that, aside from the basic mismanagement, in the process of developing a game too much passion and too strong emotions are involved. It is not just being passionate about your own work, it is something more akin to religious devotion. In my past experience people had a brawl because of misappreciation of an artist's work.
So, if the videogame is, after all, a work of art and art is about emotions and feelings, is it possible to make games and work in a sane environment?
Mazzo di carte
2014-Aug-06 Wednesday 19:55 CEST
"Ho capito che ognuno di noi nasce con un mazzo di carte diverso, chi ha il punto servito e chi un mucchio di scarti, ma questo non vuol dire che non si possa giocare lo stesso. E magari vincere. Dipende tutto da come si affronta la partita."
[Da "Morto a 3/4" di Francesco Balletta"]
2014-May-21 Wednesday 23:26 CEST
Yesterday my old friend Jimmy Playfield found a motivational poster on the wall beside his desk. Usually it is quite hard to find a motivational poster that is not lame or, worse, demotivational. And the motto on the wall was quite belonging to the latter. An ancient Chinese proverb quoted: "The person who says that it cannot be done should not interrupt the person doing it".
The intent, possibly, was to celebrate those who, despite of the adverse situation and the common sense, heroically work against all odds to achieve what is normally considered impossible.
Unfortunately reality is quite different. As that famous singer optimistically sang - One among thousand makes it. That sounds like a more accurate estimation for those trying to attain the impossible. And likely, I would add, that one is the person who benefits from advices and help from friends and co-workers.
Human kind didn't reach the moon just because someone was kept away from those who said it wasn't possible. To achieve the impossible you need a great team fully informed on why and how your goal is considered impossible. Usually great management and plenty of resource is helpful, too.
Just reminding a lesson at the University. The teacher, made this example: "Microsoft, in the search for new features to add to their compilers line may find that adding non termination detection would be great. Imagine, you write the code and the compiler tells you that no way, under these condition, your code will hang forever in some hidden loop. Wouldn't it be really helpful? But this is not possible and it has been proved by Turing". But... According to the motivational post, no one would be expected to tell the marketing and the poor programmer that volunteered for implementing the feature, that no matter how hard he tries, that feature is simply not possible (at least on Turing machine equivalents).
So that motivational sentence is basically against team work, informed decisions, information sharing, risk management.
A witty saying doesn't prove anything [Voltaire], but sometimes it is just detrimental.
Well, I was about to close here, but I just read another quote by Voltaire: "Anything too stupid to be said is sung." Well... that makes a good confrontation between Morandi and Voltaire.
2014-May-04 Sunday 22:00 CEST
Happy Birthday! BASIC just turned 50. It should have been 1981 or '82 when I first saw a BASIC listing. The magazine was named "Nuova Elettronica" (New Electronics) and it was featuring a series of column about building a computer. I remember the writer was very proud they managed to license an Italian version of BASIC. For sure it was weird (even more in hindsight), something was even understandable (LET a=3, in Italian "SIA a=3"), something else was pretty obscure (FOR i=1 TO 10, "PER i=10 A 10"). I had no computer and Internet wasn't even in my wildest sci-fi dreams, so I wondered how that lines could produce 10 hires (!) concentric rectangles.
One rather puzzling statement was LET a=a+1. I understood equations (I was at the first year of high school), but that couldn't possibly be an equation as I knew. So I tried to asked to an even more puzzled math professor, who stared at the line for a while, then muttered something about simulations and universe changing semantic.
Luckily short later another magazine "Elettronica 2000" ("Electronics 2000") started a BASIC tutorial. I read those pages until I consumed them and learned Basic. For some years programming and BASIC were quite synonyms. The first thing you saw when you switched a Zx or a Commodore on, was the BASIC prompt. The machine was ready to be programmed.
BASIC era, for me, ended with the Amiga, years later (at that age, years are eons indeed). Microsoft BASIC for Amiga was pretty unstable, also real performances can be achieved with C. Maybe the tombstone was at the second year of University, at the first lesson of Computer Science, when the professor write "BASIC" on the blackboard and then stroke it out saying: "This is the last time I want to hear about BASIC".
Talking about anniversaries, I think it is noteworthy that the first message I wrote on my blog was posted 10 years ago. I would have liked to celebrate this with a new look for my website. I have been working on this for a while now, but it is still not ready. I hope to have it on line before my website becomes of age.
Could you show me your antivirus?
2014-Mar-11 Tuesday 13:39 CET
A couple of days ago I went to the local shopping mall to buy something. At the checkout I gave my credit card and the clerk asked me for an identity document. This practice though somewhat annoying, is quite usual and is in place for protecting both the customer and the shop. Nonetheless, after what happened to Target chain I wonder if I would be entitled to ask them to show me their antivirus.
Yes, put like that is just provocative, but I am giving them a very sensitive piece of information (actually one of the most sensitive and safeguarded), shouldn't I be reassured that they took the most adequate measures to handle it properly?
The Lottery Syndrome & Other Hypothesis
2014-Mar-08 Saturday 14:19 CET
Software projects, regardless they are small or large, are likely to fail or go overtime/overbudget today not much less than they did 60 years ago. What is puzzling is that, over this period, academy and industry defined, if not a complete theory system, at least a set of rules, best practices and "don't" lists that, they claim, can provide accurate (or at least good enough) estimations for the effort required to complete a software project, while also providing a set of tools for managing such project to reach the desired objectives.
So the real question is why, projects keep failing and management keeps ignoring the wealth of evidences that would lead to a better handling of such projects.
Yesterday I watched the webinar "Software Estimation in an Agile World" by Steve McConnell. I met Steve years ago, nearly by chance, reading his book "Software Project Survival Guide". He is a great Software Engineer so listening to what he has to say on the matter is always worth the time.
At a given time in the presentation a point is made that progressing the CMM level of a company not only allows to obtain very good estimations, but also development costs are reduced.
So, what can prevent any wise company manager/owner/leader to climb the CMM ladder? I have three hypothesis and my guess is that the real reason is a specific combination of these three.
- Mystical Data. At CMM level 0 the company is in the wilderness of mystic evaluation. There are no scientific data since there is no data collection a thus no data elaboration. The company may, in "bona fide", reckon that current practice is actual faster without the burden of process.
- NAH Syndrome. Sometimes I heard this. It goes something like "yes, CMM and real process and the like are useful for large companies or for places like NASA and nuclear reactors a favourite example, but CMM is Not Applicable Here, it would cost too much and it would slow us out of competitiveness".
- "Lottery Syndrome". This is very close to the reason you may want to enter a Lottery. You know that the chances to win are low, BUT they are not zero. In the same way the company knows that driving a project without a CMM may be risky, but there is an actual chance that the outcome be a project developed in the given time and budget and in a way that makes the customer happy.
What do you think?
Quando si conoscono meglio le cose
2014-Feb-26 Wednesday 20:50 CET
L'altra giorno a pranzo Mariana: "Però essere ciechi da una parte è bello e dall'altra è brutto". Cioè? "è brutto perchè non vedi come sono fatte le cose, però è bello perchè conosci meglio le cose".
Lei prende in mano un pezzo di pane e dice: "Se uno ci vede sa già che è il pane e se lo mangia. Se invece uno non ci vede, " e a questo punto ha chiuso gli occhi, "prima di tutto lo deve prendere in mano e toccare e quindi usa il tatto. E poi quando se lo mette in bocca lo assapora e sente meglio il gusto".
Juan invece ha visto un film a scuola e con la comprovata tecnica del poliziotto buono/poliziotto cattivo (detta anche tecnica cavatappi) cerchiamo di estorcergli qualche informazione. Tanto per cambiare la vicenda è confusa: c'è una scuola, con dei bambini ciechi, con una ragazza vedente e sua madre. A un certo punto Juan confessa: "La mamma non voleva che la ragazza uscisse coi maschi ciechi". Il poliziotto buono chiede: "E perchè?". E lui "perchè ... primo, erano maschi ... e secondo non vedevano."
Reign of Terror
2014-Feb-17 Monday 14:15 CET
Thanks to linked-in pulse I stumbled in this excellent article Why my employees don't care. I wonder, how many workplace are where bosses read these kind of articles (and Peopleware and Slack, and I may go on and on)? At the end my impression is that those who read this kind of literacy are not the people who have the real power of making things happen.
I always have been at discomfort with the "Carrot & Stick" method, not to talk about the "Reign of Terror" (Project Managers are watch dogs that must shout and menacing to keep people doing what the must do). If I have to look back at my career, I expressed my profession and skills at best when I was given (or was able to get) an "insulated" framework where I could work without watchdog on my neck ready to bite me at first hesitation.
In the hope that soon or later, also those in charge will read.