The Agile Fear

This blog is no longer active. This article has been moved to Francesco’s new website. You can access the article here.

Advertisements

7 Responses to “The Agile Fear”


  1. 1 Luca Minudel 19 November 2008 at 10:11 pm

    A proposito del indice di McCabe un aneddoto

    Ho preso un programma che ho scritto per esercitarmi e ho misurato la sommatoria dellla complessità ciclomatica con NDepend prima e dopo un refactoring che ha migliorato in modo evidente:
    – la velocita di trovare classi/metodi che implementano una certa cosa
    – la facilità di capire come modificarli per fare una certa modifica
    – la velocità di verificare su quali altre funzionalità la modifica ha impatto
    – la quantità di modifiche/nuoco codice necessarie per ottenere il nuovo comportamento

    il risultato tangibile a monitor e tastiera in modo evidente e inequivocabile non si rispecchiava nei numeri della sommatoria del cc perchè le classi e i metodi estratti alzavano la somma dei cc più di quanto la abbassasse la semplificazione di algoritmi e la eliminazione di molti if

    dopo aver guardato attentamente i numeri ho visto che il risultato era dovuto al fatto che il cc è calcolato da NDepend (uno dei migliori tool di metriche per .NET disponibili) in modo approssimato

    da qui la mia domanda … ma qualcuno usa davvero le metriche per misurare qualcosa di utile o solo per giocare ?

    e la mia provocazione: una interpretazione corretta delle metriche descrittive/di verifica richiede una sensibilità che ci cel’ha … non ha + bisogno delle metriche perchè la misura ce l’ha già dal codice mentre ci lavora

    cosa ne pensi ?

  2. 2 Francesco Cirillo 20 November 2008 at 10:59 pm

    Non e’ efficace il Metric Driven Programming.

    Ci vuole sempre sensibilita’.

    Prova a misurare il McCabe Massimo. Dovrebbe funzionare sempre.

    Prova a configurare il McCabe per escludere costruttori e accessor.

    Francesco

  3. 3 Martino Vallara 31 December 2008 at 10:20 am

    “Prova a configurare il McCabe per escludere costruttori e accessor.” …

    questo perchè? E’ efficace nei costruttori avere tanti if ?

  4. 4 Michele 9 January 2009 at 4:39 pm

    Ciao,
    ho letto con interesse il tuo blog e ti ho ascoltato gia’ una volta a Roma III.

    Vorrei aggiungere solamente una mia esperienza lavorativa (sono sviluppatore senior J2EE/C++).

    Nel blog parli di un certo Marco che dice:

    “Noi siamo abituati a rispondere al cambiamento con gli IF, cosa c’è di male, funziona!…”

    A me succede qualcosa di simile, ma non dai programmatori, dai capi progetto e/o clienti e/o manager:
    la famosa frase “che ce vo’ ?” l’ho sentita ripetere tantissime volte!

    Traduco: “Che ci vuole ad implementare questo nuovo requisito? Bastera’ fare un piccolo cambiamento e funzionera’ sicuramente!”.

    NB: il nuovo requisito quando mai e’ stato valutato?

    E gia’! Che ci vuole ad aggiungere un IF qua e la’ per far funzionare il tutto?
    😦

    Riusciranno mai i nostri eroi (clienti, manager,..etc..) a guardare con piu’ professionalita’ l’attivita’ di sviluppo software?

    Forse il metodo Agile non e’ sufficiente per evitare fallimenti perche’ il cambiamento piu’ importante da fare e’ nella visione dell’attivita’ di sviluppo software: non e’ banale scrivere SW, non lo possono fare tutti e serve una elevata professionalita’ e preparazione per farlo.

    Gia’ interessarsi alla metodologia Agile indica un attegiamento professionale (e serio) che manca spesso in italia (e a roma in particolare).

    Ciao
    Michele

  5. 5 Mike 5 February 2009 at 2:57 pm

    Ciao Francesco,
    leggo sempre i tuoi blog con interesse, ti ho ascoltato una volta in un seminario all’universita’ ( Roma 3 ).
    Mi hanno colpito diversi punti in questa storia che hai raccontato.
    Uno di questi riguarda il refactoring:
    “Per non parlare dei team che realizzano il refactoring .. Riusciranno a mettere in discussione il loro modo di intendere il refactoring? ”

    Una volta parlavo con il mio capo progetto su che cosa occorrerebbe fare per aumentare la qualita’ del SW, e soprattutto per consegnare un prodotto con meno bug possibili.

    Quello che sostenevo e’, tra le altre cose, che sarebbe necessario che le persone facessero periodicamente del refactoring del proprio codice (tenendo presente le metriche), in modo tale da non trovarsi tra le mani un prodotto non flessibile, difficilmente modificabile/comprensibile e pieno zeppo di bug.

    In fondo, le metriche sono facili da capire e applicare!

    In tutta risposta il capo mi ha detto:
    “gli sviluppatori bravi non hanno bisogno di tornare indietro sul codice che scrivono, sarebbe una perdita di tempo, le persone brave pensano [pensano, ma non fanno UML perche’ fa perdere tempo! n.d.] il codice e lo scrivono gia’ correttamente, quindi il refactoring non va fatto”

    C’e’ qualcosa in cui sbaglio nella mia concezione del SW?
    Credo che le metriche andrebbero usate sempre, cosi’ come i diagrammi UML, cosi come tecniche come il TDD…

    C’e’ qlcs di sbagliato nei diagrammi UML?, o nel refactoring?, o nell’esigenza di disegnare prima, e scrivere poi ????

    Ha ragione il capo a dire che i “bravi” non fanno refactoring?

    Probabilmente non sono bravo io…

    Ciao

  6. 6 Francesco Cirillo 8 February 2009 at 2:43 am

    Probabilmente neanche io 🙂

    Metriche, TDD, refactoring, UML sono tutte pratiche che vale la pena usare se finalizzate ai nostri obiettivi: un software flessibile, testabile, consegnabile.

    C’e’ da dire che quando non finalizzate ai nostri obiettivi e quando invece il nostro obiettivo e’ quella pratica – una sorta di forma d’arte 🙂 – beh diventano spreco.

    Il punto importante e’ capire che definizione di FATTO diamo al nostro codice. Cosa vuol dire quando andiamo dal capo e gli diciamo “sai la funzionalita’ che mi avevi assegnato… FATTA”. Il primo impegno lo dobbiamo prendere con noi stessi rispetto agli obiettivi che intendiamo raggiungere…

    In bocca al lupo!

    Francesco

  7. 7 Francesco Cirillo 8 February 2009 at 2:47 am

    Hai ragione. Per me la prima domanda da porci e’: ma come mai davanti ad un cambiamento che dal punto di vista business e’ cosi’ semplice, io impiego tanto sforzo!

    Spesso ai clienti non si puo’ rimproverare proprio niente. Se il numero di una pagina in un report lo vogliono spostare da destra a sinistra non penso che si aspettino molto tempo per realizzare il cambiamento da parte dei programmatori.

    Invece spesso davanti a questi cambiamenti minimi nel business il programmatore, per inesperienza nel design arriva a rispondere “non so quanto ci mettero'” o addirittura “forse non si puo’ fare”…

    Per Roma, sii fiducioso 🙂

    Francesco


Comments are currently closed.



Follow Francesco on:

FacebookLinkedinTwitter

Anti-IF Campaign

Blogroll

Recent Twitter Updates

Error: Twitter did not respond. Please wait a few minutes and refresh this page.