agosto 2006 Blog Posts
Nel libro Peopleware è riportato uno studio di due ricercatori dell'Università del New South Wales di nome Michael Lawrence e Ross Jeffery, i quali hanno misurato la produttività di progetti stimati in diversi modi. Ecco la tabella con i risultati:EFFORT ESTIMATE BYAVERAGE PRODUCTIVITYNUMBER OF PROJECTSProgrammer alone8.019Supervisor alone6.623Programmer & supervisor7.816System analyst9.521(No estimate)12.024Questo studio è del 1985, le metriche utilizzate sono simili alle CoCoMo sostenute da Barry Boehm.Da questo studio è emerso che:Il manager che non consulta il programmatore per stimare un progetto ha i risultati peggiori.Le stime migliori sono quelle fatte da chi ha esperienza nello stimare...
Tanto per fare l'anternativo ;-)
Ecco il link su Code Project, ad una prima occhiata sembra ben fatto.
E' un post un pò provocatorio, ma vale la pena leggerlo.
P.S.: Assicuratevi che il vostro browser abbia il blocco dei popup attivato.
Fonte: reddit
L'Ortogonalità è un concetto critico se si vogliono produrre sistemi software che siano semplici da progettare, sviluppare, testare ed estendere.
In geometria due rette sono ortogonali se la loro intersezione forma un angolo di 90° gradi, in termini vettoriali si dice che sono indipendenti.
Nel campo informatico l'ortogonalità indica disaccoppiamento. In un software ben progettato il codice che accede al database è ortogonale alla user interface, cioè possono modificare la user interface senza dover toccare il database e viceversa. Maggiori dettagli li potete trovare nel libro The Pragmatic Programmer nel capitolo Orthogonality.
Questo concetto si può applicare a diversi...
Ecco il link, l'intervista è in inglese.
Jacob Nielsen è uno dei guru sull'usabilità del web, ha scritto diversi libri sull'argomento, ne consiglio l'ascolto contiene molti spunti interessanti anche per noi developer che a volte ne sottovalutiamo l'importanza.
Vorrei consigliare a tutti coloro che gestiscono delle persone, in particolare un gruppo di sviluppo software la lettura del libro Peopleware - Productive Project and Teams.
E' uno di quei libri che ti apre la mente con un sacco di riflessioni interessanti e dati raccolti da progetti reali.
Riporto alcune frasi che mi hanno complito particolarmente:
The major problems of our work are not so much technological as sociological in nature.
Dal 1979 hanno chiesto alle persone che hanno partecipato ad un progetto fallito cosa era andato storto; per la stragrande maggioranza dei casi non c'è stata neanche una...
Il link: My Top 11 Usability Tips Gleaned From All Over
In particolare sono concorde sul consiglio di leggere il libro Don't Make Me Think: A Common Sense Approach to Web Usability di Steve Krug.
Come promesso ecco le risposte del quiz del post Assertive Programming - Come evitare l'impossibile, segue un piccolo quiz
Quale di queste affermazioni impossibili può accadere?
1. Un mese con meno di 28 giorni
Risposta: Il mese di Settembre del 1752 è durato solo 19 giorni, a causa della riforma del Calendario Gregoriano.
2. Directory.GetFiles("."); segnala un eccezione (cioè non è possibile accedere alla directory corrente)
Risposta: Ad esempio se la directory è stata rimossa da un altro processo.
3. In c#: a = 2; b = 3; if (a + b != 5) Console.WriteLine("Questo è impossibile");
Risposta: Non sono...
Quante volte di fronte ad una segnalazione di un problema da parte di un utente abbiamo pensato o detto "Questo è impossibile...".
Trovo molto efficace il Tip 33 del libro The Pragmatic Programmer:
If It Can't Happen, Use Assertions to Ensure That it Won't
Il modo più semplice per seguire questo consiglio è quello di usare il metodo Assert del framework. Segue un semplice esempio:
public void WriteString(string s){ Debug.Assert(s != null); // Segue il codice della funzione}
Si deve fare attenzione che il codice della Assert non abbia side effects e, soprattutto, non inserire codice che deve essere eseguito per...
Segnalo questo post del blog The Mindset di Lidor Wyssocky.
Uno dei passaggi su cui sono completamente d'accordo:
Respect is indeed the greatest reward. You cannot expect your employees to be motivated, innovative, and productive, if you don’t respect them. It’s that simple!
Ed ancora:
Well, it isn’t really that simple. This might be one of the hardest changes to make in an organization. I am almost tempted to say that you are either born with the ability to respect others or you’re not.