Penso che mi si possa definire un entusiasta appassionato di computer ed elettronica, avendo iniziato ad usare i PC da quando ancora si chiamavano “home computer”. Ho passato però abbastanza tempo alla tastiera per raggiungere una certa obiettività la cui estrema sintesi con un po’ di esagerazione potrebbe essere riassunta dalla Quinta legge dell’inattendibilità: “Errare è umano, ma per incasinare davvero tutto ci vuole un computer”. E’ con questo spirito critico che accolgo le roboanti e propagandistiche dichiarazioni sulla Scuola 2.0 (qualunque cosa questo voglia dire).
E da veterano del byte mi preoccupo – perchè la scuola che vedo e che sento è una scuola agonizzante che avrebbe bisogno di quegli investimenti per ristrutturazioni, materiali didattici (per non parlare della carta igienica), personale qualificato, ma che sicuramente non ha bisogno di ulteriori responsabilità e problemi che potrebbero verosimilmente darle il colpo di grazia.
Infatti quello che manca in tutti gli articoli che ho letto è un dato di realtà, iPad e PC non sono taumaturgici oggetti che con la sola presenza hanno il potere di trasformare legioni di studenti caproni e ignoranti in eleganti dottori dal QI a fondo scala. Ci sono vantaggi, sicuramente, ma ci sono anche dei costi indiretti e delle problematiche d’uso. Cose di cui non v’è menzione in alcun articolo.
Un esempio stupido stupido è che iPad e netbook hanno bisogno di energia, ve lo immaginate in una classe un povero docente che fa lezione con un terzo degli studenti che deve ricaricare l’aggeggio elettronico, magari tra prese volanti e prolunghe collegate ad un impianto elettrico fatiscente?
O sempre lo stesso docente che si trova con metà classe che naviga su facebook anzichè leggere Petrarca? O che deve aspettare qualche minuto perchè tutti abbiano finito di accendere il PC?
E chi si occuperà di aiutare gli studenti a configurare il dispositivo, a sistemarlo quando, inevitabilmente, perderà la configurazione o i dati saranno danneggiati? E quando si perderà o si romperà? Un libro di testo sopravvive tranquillamente ad un volo da una finestra del terzo piano (magari si squinterna un po’, ma rimane comunque utilizzabile per il suo scopo), non si può dire lo stesso di un iPad.
Si dirà che queste scelte favoriscono le famiglie abbassando i prezzi dei libri di testo. Può essere, ma non ho letto nulla, in questi articoli, riguardo alle reali differenze tra un libro elettronico e un libro cartaceo.
A meno che non si espressamente richiesto dal legislatore sul tema libri di testo, un editore può rendere l’e-book nominale (non potrà essere ri-venduto, prestato o stampato senza cadere nell’illecito), revocabile |è capitato con 1984 di Orwell ed Amazon], o con data di scadenza (mi dicono che alcuni libri di testo scadono dopo 3 anni).
Nessuno ha sollevato il dubbio che studiare su un LCD retroilluminato può dare problemi alla vista e alla concentrazione (già pericolosamente in bilico tra Petrarca e Facebook).
Anche ammesso e non concesso che questa sia la via da seguire per il futuro, perchè nessuno ha messo in discussione le scelte? Ad esempio i lettori eInk sarebbero sicuramente più adeguati. Android invece di iPad sarebbe più economico. OpenOffice e Linux invece di Microsoft sarebbero gratis.
E’ difficile non pensare che dietro a questi pomposi annunci ci sia un duplice intento che poco ha a che vedere con la reale innovazione dichiarata. Da una parte si strizza l’occhio ai ragazzi (prossimi elettori) con la promessa di un elettronico oggetto del desiderio e dall’altro si fanno gli interessi di Apple e Microsoft e qualche grosso produttore di portatili.
Non ultimo, ma non trascurabile, non ho visto nessuno affrontare il tema dell’impatto sociale di queste operazioni. Personalmente credo che i lavori in obsolescenza vadano lasciati andare senza tenerli artificialmente in vita a tutti i costi a spese dei contribuenti (anche se sono altresì convinto che, a spese dei contribuenti, gli addetti debbano essere aiutati a riqualificarsi, a cercare un nuovo impiego e sostenuti in questo periodo di transizione). La rivoluzione Scuola 2.0 impatterà sicuramente su tipografie, magazzini, trasporti e librerie e cartolerie; probabilmente ci si aspetta che la nuova generazione di geni creata a suon di iPad e eBook risolva questo problema (e tutti gli altri).
Necessary, but not Sufficient
“How can you say that 2+2 is not 5?! Never ever?! It is only because you believe this. For sure there will be someone, out there, better than you at this, that will be able to make 5 out of 2+2.”That’s about the transcript of a heated discussion I overheard in a near office. Though they were not talking about mathematics, but physics. Basically my colleague was claiming that a given result could not be achieved because of something that is physically not possible.
Just a few days ago I wrote about seeing atoms and that something considered not possible should be considered (basically) as an opportunity in disguise. So I felt the urge of sharing a couple more of thoughts.
It is important – I believe – to clear out the distinction. Photons do not hit a single atom (I’m sure that this is not a formally correct assumption, but it is just for getting the hang of it), so it is true that you can’t see single atoms. And human race stood with that for quite a long time. Then someone had the technology to build a mapping of atoms into a display screen and made the magic, but it is still true that you cannot watch them with your bare eyes or any powerful optical microscope.
It doesn’t matter how much you boss yells at you, it is something that cannot be done. And it would still be impossible if you don’t have the budget to build a complex machinery that does the job with special sensors. If your customer requirements is – I wanna see atoms bare eyes, then it IS impossible.
If you want a significant advance, then you have to mix lateral thinking and quite a lot of money. But, most of all, you have to be ready to accept that though these conditions are required, they do not grant any result.
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.
You can’t see atoms
You can’t see atoms. That’s what I was taught. Well, everything you see is actually made by atoms, but you can’t see single atoms – that was the meaning of the teaching. Simply it is not possible – it has to do with atom dimensions and light wavelength. I won’t delve into the scientific reasons, but every serious physic textbook will confirm this.You may imagine my surprise when I saw some pictures of actual molecules. In fact it is true that you can’t see atoms (nor molecules), but you can use specialized sensor to produce a visual representation of atoms and molecules aspects. Yes it is not seeing directly by light rays, but is fully equivalent for all practical purposes.
That’s the idea – something is considered impossible until someone comes out with an idea to work around the limitations and voila, what once was considered impossible, today is within everyone reach.
This is what my friend Jimmy Playfield (the name is fake to protect his privacy) told me.
Some days ago Jimmy’s boss called him and all senior programmer and senior hardware designers to assign them a homework for the short vacancy they were about to have.
The goal was to find a way to work in the company environment and successfully craft project after project. The constraint though were that they couldn’t change anything in the chaotic way projects were handled.
Here is a sum of the constraints –
- budgets are fixed, no increase in the engineers workforce;
- requirements are roughly defined at the beginning of the project, then they continue to pour in during the entire lifetime of the project;
- Resources are not statically assigned to a single project, but they may be temporary (and not so temporary) shared among two (or more) projects;
- contracts are naively written, no real fences and firewall are set to force the customer to behave constructively nor to protect the company from customer whims;
- project manager role has been declared useless, so their company charges the responsibilities of project management onto project specialists;
- there are more projects than programmers;
- no real policy for resource management, no motivational incentives, no benefits, no training (well, here I guess Jimmy was somewhat exaggerating).
Easy, ain’t it?
Well it sounds a hard problem. Let’s see what “project management 101” has to say about this situation.
First the triangle of project variables. Basically for every project there are three variables – Budget, Features and Time. Of these three variables you can fix two (any two), but not the third one. E.g. you can fix Time and Features, but the Budget is a consequence, or you can fix Budget and Time, but Features are a consequence (this is the agile methodology configuration.)
Usually projects at Jimmy’s company have Budget and Time fixed. So the only chance would be to work on Features.
Features variable is to be intended as a mix of features and their quality. A poorly implemented feature is likely to take less time/budget than a robust and top quality implementation. So they could slash the quality.
The problem to work in this direction – put aside ethical aspects – is that usually quality is the topmost motivational driver. Taking pride of what one does helps the involvement in the project. When a programmer in despair states – “tell me what I have to do and I’ll do it” – that’s the end of motivation, the end of involvement and the sunset of efficiency. The programmer will consider that project an accident, something that is not worth his/her neurons to be burnt on.
The other problem in slashing the quality is that legal contracts have to be armored to protect the company against the customer that could complain about the lack of quality.
I can’t see any solution for them, at least, not within the system, much like you can’t see the atom without moving to another level.
So by moving to a meta-level, you can break out of the system, e.g. by hiring someone to write the code for the project. This programmer won’t do any better than Jimmy and his coworkers – sometimes he will complete the project, sometimes he will fail. But to the company is a win-win solution, if the contractor succeeds then the company wins, if the contractor fails then the company could blame him and that’s a win again.
The major problem I see with this is that it is a bit suicidal, i.e. Jimmy and his coworkers become redundant and disposable as soon and the contractor is hired. Good luck, Jimmy and let me know if you find a better solution.
Estate curiosa
Tra tempeste di Halloween e Sandy d’oltremare, freddo a norme stagionali dopo una autunno mite, è facile farsi prendere dalla voglia di riguardare le foto della scorsa estate… Soprattutto quelle archiviate alla voce “Buffe”.
 |
Naxos, isola delle cicladi, rinomata per le sue famose sabbiature. |
 |
Non puoi distrarti un attimo che ti ritrovi coperto di sabbia… e a volta anche da un secchiello rosso. E’ tipico della zona come il feta e l’ouzo. |
 |
E se riesci a scampare alle sabbiature non è scontato che riesci a scampare ad altri loschi individui (dovrei dire affascinanti individui dallo sguardo intelligente, ma proprio non ci riesco) |
 |
Con tutti questi problemi in spiaggia è chiaro che si rimane tutti un po’ più nervosi la sera e la semplice domanda “cosa mangiamo?” può scatenare incredibili reazioni. |
 |
Che hanno ripercussioni anche il giorno dopo. |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
Adesso si che il grigio di fine autunno è dissipato!