Measuring Lines of Code

Mi e’ piaciuta molto questa frase di Kent Beck da una mail sulla lista xp americana, sull’uso del numero di linee di codice come metrica di produttivita’:

Lines of code has many limitations — it’s like measuring a factory based on its consumption of raw materials not on its output.

Ricorda un po’ quella di Edsger W.Dijkstra

Yet people talk about programming as if it were a production process and measure “programmer productivity” in terms of “number of lines of code produced”. In so doing they book that number on the wrong side of the ledger: we should always refer to “the number of lines of code spent”.

Come Object Mentor guida la transizione XP dai propri clienti

Di recente Bob Koss di Object Mentor ha pubblicato un post sul possibile cattivo uso della velocity come metrica di processo.

A parte il tema del post, Bob parla anche di come tipicamente Object Mentor guida la transiziona ad XP dai loro clienti. Prima di tutto tengono un corso su XP per tutti (gruppo di programmatori e gruppo di customers).

When Object Mentor does an XP transition with a client, we start with our XP Immersion course to get everybody on the same page about what our goals are.

Poi due istruttori seguono separatamente i due gruppi, uno insegna ai programmatori le pratiche piu’ tecniche, l’altro invece affronta con i customers le pratiche di planning e managing del progetto XP (scrivere le carte, le iterazioni, la pianificazione incrementale, …)

Ideally, we use two instructors, one to train the programmers in topics such as Test Driven Development and Refactoring, and the other coach teaches story writing, iteration planning, and release planning to the customer team.

Poi i due gruppi lavorano assieme per un giorno intero ad un progetto di prova, per far vedere a tutti come funziona il processo XP

We then bring the two groups together for a day and have the customer team drive the programming team on a classroom exercise so everybody can experience how the process works.

I due mentor rimangono poi per seguire le prime iterazioni del progetto “vero”

The instructors then stay and work with the team for a few iterations, coaching them on how to use what they learned in class on their own project.

E poi tornano di tanto in tanto per vedere come vanno le cose, magari partecipano alle retrospective di iterazione per vedere quali sono i problemi, come vanno le metriche (in questo caso la velocity).

Interessante, no?

Quanto meno perche’ mi fa riflettere su quali siano i modi migliori per introdurre XP in una realta’ nuova. Certo, qui c’e’ un cliente che coscentemente decide di adottare XP e paga (tanto immagino) per essere guidato nella transizione verso un processo agile.

La realta’ in cui invece mi trovo io e’ diversa, si deve procedere in modo incrementale, a piccoli passi, perche’ qui nessuno (tra i dirigenti almeno) ha chiesto di adottare XP, anche se c’e’ molto interesse e (qualche) consapevolezza dei punti deboli dell’attuale processo. C’e’ quindi un lavoro doppio, dal basso verso i programmatori e dall’altro verso i manager, per far vedere i piccoli miglioramenti che si possono ottenere lavorando in modo agile. Miglioramenti che consentono di lavorare in modo piu’ divertente e soddisfacente (il famoso “ease at work” di cui parlava Kent Beck in una sua presentazione tempo fa’).

Vabbe’ magari ne parlero’ in un altro post, visto che sto andando fuori tema!

Alla prossima!

Le metriche del codice per quelli della NASA…

Ieri stavo leggendo questo articolo datato 1997 sulle metriche, pubblicato sul sito di un centro della NASA (Software Assurance Technology Center, http://satc.gsfc.nasa.gov/), che tra l’altro ha una sezione dedicata proprio alle metriche nel software (http://satc.gsfc.nasa.gov/metrics/index.html e http://satc.gsfc.nasa.gov/metrics/codemetrics/index.html).

Vabbe’, in questo articolo si presentano diversi tipi di metriche, sia tradizionali che OO.
Quando parla del numero ciclomatico dice: “In general, the cyclomatic complexity for a method should be below ten, indicating decisions are deferred through message passing.

Un altra metrica tradizionale e’ poi la seguente:
METRIC 3: Comment Percentage
The line counts done to compute the Size metric can be expanded to include a count of the number of comments, both on-line (with code) and stand-alone. The comment percentage is calculated by the total number of comments divided by the total lines of code less the number of blank lines. The SATC has found a comment percentage of about 30% is most effective. Since comments assist developers and maintainers, this metric is used to evaluate the attributes of Understandability, Reusability, and Maintainability.

Quanti progetti legacy per quelli della NASA avrebbe delle ottime metriche? :-)

E comunque voi sapete come mai anche il piu’ recente studio sulle metriche OO non arriva al 2000?!

Cercando su google ho trovato articoli vecchi, nessun nuovo studio, niente di niente!
Come mai?

Affinare la metrica

La recente discussione in seno al team XPlayers di Quinary sulle nostre metriche e su come affinarle mi ha fatto riflettere un po’ e volevo condividere con voi questi pensieri, ovvero una proposta di cambiamento della metrica (da sottoporre a prova sul campo, si intende).

Il nostro magic number, dopo varie discussioni su quali fattori includere, e’ stato definito all’inizio in questo semplice modo

Magic Number = NCSS / (LCOM * CCN)

dove le premesse erano che (ditemi se sbaglio):

se NCSS cresce e’ un bene (maggiore produttivita’?)

se LCOM scende e’ un bene (maggiore coesione)

se CCN (McCabe) scende e’ un bene (minore complessita’ “di flusso”)

Io penso che in questa formula NCSS abbia un peso troppo forte, e questo favorisce oscillazioni come quelle che abbiamo osservato nelle scorse settimane (vedi thread su “Metriche di oggi”).

Ora, non so per certo se queste oscillazioni siano giuste o meno, e capisco anche che, cosi’ come esiste il ‘debito di refactoring’ quando si scrive molto codice ma lo si rifattorizza poco, possa esistere una sorta di ‘debito di produttivita diretta’ quando si rifattorizza molto (e quindi si produce un delta di NCSS piccolo o addirittura negativo).

Pero’ penso che sia giusto far entrare nella formula un fattore che premia il codice rifattorizzato, e pertanto propongo di provare la seguente formula

Magic Number = NCSS / (LCOM * CCN * lunghezza media dei metodi)

dove lunghezza media dei metodi = NCSS / #metodi

il che significherebbe, semplificando i fattori

Magic Number = #metodi / (LCOM * CCN)

questa variazione permette secondo me (ma vorrei provarla per avere una qualche certezza) di premiare certamente la produzione di codice (come accadeva per l’NCSS), ma di codice rifattorizzato (che poi sia ben rifattorizzato questo non saprei come misurarlo).

In altre parole se scrivo tanto codice nuovo, ma lo metto in pochi metodi grossi ho un incremento minore di quanto non avrei se lo stesso codice fosse messo in metodi piu’ brevi e concisi.

Che ne dite?