Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register

CowBoy Coder

O gioia! O gaudio! O Tripudio!

No, non sono ammattito (non piu' del normale), e' solo che mi hanno appena comunicato che la stramaledetta applicazione di gestione del foxxuto Mailscan, quella che abbiamo madonnato tanto per mettere in produzione e che ha piu' buchi di una forma di gruviera, non dovro' mantenerla io!

Oggi, alla solita riunione di gruppo, siamo (sono) stati informati che un tizio (sedicente "programmatore") e' stato selezionato per fare la malnutrizione dell'accrocchio. Il tizio passera' di qui nel pomeriggio per una visita e poi se ne ritornera' a casa sua in Canada...

Devo ammettere che quest'ultima parte mi ha lasciato con un senso di deja-vu' di Jugoslavi vari.

Comunque, meglio lui che io. L'applicazione intendo, non il Canada.

Nel pomeriggio arriva questo tizio (ST) e ci sediamo a guardare la maledetta cosa.

ST - ...e comunque io pensavo ad un rifacimento totale della cosa.
IO - ??? Comesarebbeadire??? L'abbiamo appena messa in produzione questa cosa!
ST - Si ma e' orrenda, cosa e' questo schema di colori? Nero, marrone e blu?
DB - (che e' l'autore dello schema dei colori) Hemmm... lasciamo perdere lo schema colori, per il momento quello che vogliamo e' correggere i bug che sono presenti e che ci danno i maggiori problemi, che sono una mezza dozzina.
ST - E questi testi fanno ridere!
DB - (che e' l'autore dei testi) Lascia stare i testi. Per prima cosa il problema della password...
IO - Io direi prima di tutto di mettere a posto il controllo dei domini che non accetta domini con '-' e che dobbiamo quindi aggiustare manualmente.
ST - Ed i font sono tutti sbagliati, anche l'allineamento delle maschere...
DB - (che e', ovviamente, l'autore dei font eccetera eccetera) Lassa pedere ste cazzate! L'elenco dei bug da correggere te l'ho dato. Questo e' quello che devi fare. Okkey?
ST - Ah, ma quello che pensavo io era un rifacimento completo...
DB - L'ho capito che quello che vuoi fare tu e' un rifacimento completo, ma quello invece che devi fare e' correggere questi quattro
mepensa: o otto, o dieci...
DB - bug che ci danno dei problemi!
ST - ...perche' ripartendo da zero e' molto piu' semplice.
IO - Mi lascia piuttosto perplesso sentire che rifare da zero qualche cosa e' "piu' semplice" che correggere alcuni bug in una applicazione che fondamentalmente funziona.
ST - Ah ma perche' io uso solo FlexibleProgramminReshuffled.
IO - Tu usi cosa?
ST - Si', e' l'ultima frontiera, e' Agile Programming agli steroidi.
IO - Ah si?
ST - Si, per prima cosa si scrivono i TestModule per verificare che tutto funzioni (mepensa: e come verifichi che tutto funzioni se ancora non hai scritto niente che funzioni?), poi si procede a scrivere il CoreCoding in modo incrementale e quindi si aggiungono i test funzionali...
DB - (che sta incominciando a pensare che ST sia una pessima idea) Bravo! Adesso pensa a correggere questa mezza dozzina di bug.
ST - Ma perche' sicuramente questa applicazione sara' stata scritta da un qualche Cowboy Coder.
IO - "CowBoy Coder"?
ST - Ma si, questa gente che si mette a scrivere codice sempre per eseguire funzioni specifiche, senza CoreCoding.
IO - E che sarebbe questo "CoreCoding" esattamente?
ST - L'uso di libreria object-oriented ad alta astrazione ovviamente.
IO - Ah che strano... anche H & K erano degli aficionados di quella roba.
ST - Ah si?
IO - Si. Ed infatti e' per quello che abbiamo tutti quei bug. Perche' sono talmente astratte da essere astruse.

Dopo un paio d'ore, quando il pericoloso individuo ha preso il largo, DaBoss arriva a parlarmi.

DB - Speriamo che riesca a correggere questi quattro bug prima della fine dell'anno.
IO - Io dubito seriamente che quello sia in grado di scrivere del codice funzionale, comunque mi associo nella speratura.
DB - Ma tu che ne pensi?
IO - Che e' un coglione.
DB - Ah si?
IO - Tu ci hai presente il backend di mailscan si? Quello che gestisce tutto l'ambaradan che supporta oltre 8000 domini eccetera eccetera? Bene, non c'e' una sola libreria Object-Oriented in tutto l'arnese. E se c'e' un "CowBoy Coder" qui dentro, sono io.

Yippie kai yay partner!

Davide
28/09/2009 08:00

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

75 messages this document does not accept new posts
Herr Franzsecondo me... By Herr Franz - posted 28/09/2009 08:08
Secondo me i casi sono 3 :
o si mette a farla da capo, dicendo che era l'unico metodo ,
o fa finta di metterci mano per un mesetto e poi chiede di passare al punto uno,
o la guarda , non ci capisce niente , e passa prima al punto 2 e poi al punto uno.
A vostre spese.
Questo si chiama goto informatico detto anche "ma va' a...".

--
Herr Franz


Guido@ Herr Franz By Guido - posted 29/09/2009 17:01

Il fatto che se è un programmatore in J(f)ava ti risponde che il goto non è disponibile ;\)


> Secondo me i casi sono 3 :
> o si mette a farla da capo, dicendo che era l'unico metodo ,
> o fa finta di metterci mano per un mesetto e poi chiede di passare al punto uno,
> o la guarda , non ci capisce niente , e passa prima al punto 2 e poi al punto uno.
> A vostre spese.
> Questo si chiama goto informatico detto anche "ma va' a...".
>
>

--
Guido


Luca BertoncelloI famosi Tests!! By Luca Bertoncello - posted 28/09/2009 08:22

Bella, l'idea!

Ce l'aveva anche il mio (ex!) capo (quello che e' scappato l'anno scorso).
Ha fatto "assumere" uno studente per scrivere i vari Tests intanto che io ancora dovevo scrivere il codice.
I Tests non hanno MAI funzionato, ma il programma va a meraviglia...

Per fortuna, poi, il tipo e' andato via, che voleva farmi riscrivere il codice per farlo funzionare con i Tests (e probabilmente poi, non funzionare AFFATTO nel mondo reale...).

Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)

Ciao

--
Luca Bertoncello


Davide Bianchi@ Luca Bertoncello By Davide Bianchi - posted 28/09/2009 08:30

> Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)

Come sei perspicace...

--
Davide Bianchi


Elder@ Davide Bianchi By Elder - posted 30/09/2009 12:51

> > Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)
>
> Come sei perspicace...
>
questo vuol dire che ci aspettano altre storie su di lui, bello :D (per noi, non per te temo :P)

--
Elder


Anonymous coward@ Luca Bertoncello By Anonymous coward - posted 28/09/2009 09:35

> Bella, l'idea!
>
> Ce l'aveva anche il mio (ex!) capo (quello che e' scappato l'anno scorso).
> Ha fatto "assumere" uno studente per scrivere i vari Tests intanto che io ancora dovevo scrivere il codice.
> I Tests non hanno MAI funzionato, ma il programma va a meraviglia...
>
> Per fortuna, poi, il tipo e' andato via, che voleva farmi riscrivere il codice per farlo funzionare con i Tests (e probabilmente poi, non funzionare AFFATTO nel mondo reale...).
>
> Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)
>
> Ciao

I test di unità (cosė si chiamano) sarebbero anche una bell'idea in linea teorica: scrivi una piccola porzione di codice che testa una funzionalità e poi passi il tuo sorgente al framework di testing che ti dice quanta roba funziona e quanta roba c'è da sistemare. Se aggiungi una nuova feature puoi vedere dove questa va ad influire e con che conseguenze.

Il problema è che si tratta dell'ultima novità in fatto di OOP e quindi tutti i baboon coders che a malapena distinguono un'interfaccia da una classe astratta ci si sono fiondati sopra come api sul miele.

--
Anonymous coward


FranzOO : siamo uomini o utenti? By Franz - posted 28/09/2009 08:53

Io, lo ammetto, non sono mai stato un grande fan della OOP.
La uso, ne vedo i benefici, non intendo dire che sia da gettare completamente... pero'...

Per me la OOP ha contribuito a trasformare i programmatori in Utenti, di codice che altri hanno creato (spesso male), senza capire esattamente cosa succeda "dietro le quinte".
Un mio amico, ex coder, chiamava windows -l'allora 3.11- "Pupazzetti&Bamboline" ed i programmatori visual-basic li chiamavamo poi "utenti".

Il risultato di tutto questo è che il computer con il quale è stata gestita la missione Apollo nel 1969, non riuscirebbe a far girare notepad, oggigiorno.
E' quello che fa si che Excel conntentga buona parte del codice del Flight Simulator.
Dietro a questi "grandi successi" c'e' sempre un genio che si mette in testa di creare un'altro livello di astrazione sopra a quelli gia' esistenti.

--
Franz


Kent Morwath@ Franz By Kent Morwath - posted 28/09/2009 22:35

> Io, lo ammetto, non sono mai stato un grande fan della OOP.

Chiunque si trovi a creare applicazioni GUI Windows, o si cimenti con le OCI di Oracle apprezza rapidamente una libreria OO ben fatta. E anche MacOSX è in gran parte basato sugli oggetti ereditati da NextStep :\)

> Per me la OOP ha contribuito a trasformare i programmatori in Utenti, di

Solo quelli che non mettono a disposizione i sorgenti delle librerie, e quelli che quando li hanno non ci buttano un occhio.

> visual-basic li chiamavamo poi "utenti".

VB fino a .NET non è mai stato veramente OO per il semplice fatto che mancava l'ereditarietà (e pertanto anche il polimorfismo, se non via COM).

> la missione Apollo nel 1969, non riuscirebbe a far girare notepad,

Mah, il software a bordo dell'Apollo ha avuto i guai suoi.., per chi vuole la storia completa: http://en.wikipedia.org/wiki/Apollo_Guidance_Computer

> Dietro a questi "grandi successi" c'e' sempre un genio

A volte è necessario, perché altrimenti la complessità di un sistema va ben oltre le possibilità di gestione. Poi ci sono i talebani come alcune librerie Java che per gestire la pressione di un pulsante bisogna implemetare quattro design pattern e otto classi :\) Perché cosė è più "elegante".

--
Kent Morwath


Nikriassumendo: By Nik - posted 28/09/2009 09:47

> DB - Ma tu che ne pensi?
> IO - Che e' un coglione.

quando una parola dice tutto......

--
...


Stefano L.Ma tu guarda che combinazione By Stefano L. - posted 28/09/2009 10:48

Questa mattina arrivo in ufficio e sulla mia scrivania trovo una rivista. (Chissa' chi l'ha messa)
La sfoglio e noto che parla di... AG !
Scorro qualche articolo, AgileProgrammint, TestingAutomatico, MassimizzareLaComunicazione, PairProgramming, Refactoring....ecc.

Chissa' come mai mi viene in mente il famoso commento di Fantozzi alla corrazzata Potemkin

--
Stefano L.


JohnnyTDD By Johnny - posted 28/09/2009 10:55

Quando lavoravo come programmatore a $noiVendiamoSuonerie usavamo Test Driven Development: prima si scrivevano i test e poi si scriveva il test per non farli fallire.
Sembra una stupidata, ma non lo è: ti garantisco che se parti da zero, alla fine ti ritrovi con il codice molto pulito e diventa semplice anche fare una modifica.
Ovviamente questa metodologia ha i suoi svantaggi, ma in certi contesti (non nel tuo caso!) funziona bene

--
Johnny


mauaggettivo per ST By mau - posted 28/09/2009 11:09

> DB - Ma tu che ne pensi?
> IO - Che e' un coglione.

ce la scrivi in olandese? :D

--
Mau


Davide Bianchi@ mau By Davide Bianchi - posted 28/09/2009 11:15

> ce la scrivi in olandese? :D

Wat denk je?
Wat Hij een idioot is.

Tevreden?

--
Davide Bianchi


Anonymous coward@ Davide Bianchi By Anonymous coward - posted 28/09/2009 11:25

> > ce la scrivi in olandese? :D
>
> Wat denk je?
> Wat Hij een idioot is.
>
> Tevreden?

Hai barato, non è la traduzione "letterale"

--
Anonymous coward


Davide Bianchi@ Anonymous coward By Davide Bianchi - posted 28/09/2009 11:28

> Hai barato, non è la traduzione "letterale"

No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.

--
Davide Bianchi


Anonymous coward@ Davide Bianchi By Anonymous coward - posted 28/09/2009 11:32

> > Hai barato, non è la traduzione "letterale"
>
> No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.
>
>
>
nel senso che non esiste una traduzione di co$$$one in olandese?

--
Anonymous coward


Davide Bianchi@ Anonymous coward By Davide Bianchi - posted 28/09/2009 11:39

> nel senso che non esiste una traduzione di co$$$one in olandese?

Non letterale.

--
Davide Bianchi


Antonio@ Davide Bianchi By Antonio - posted 02/10/2009 13:46

> > Hai barato, non è la traduzione "letterale"
>
> No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.

Infatti le traduzioni sono come le donne:
Se sono belle non sono fedeli, se sono fedeli non sono belle
:)

>
>
>

--
Antonio


AlexConcordo, a meta' By Alex - posted 28/09/2009 11:30

Mi aggrego al disprezzo per l'Agile e in particolare per il Test-Driven Programming che considero una minkiata, nonostante sia da una decina d'anni che evengelisti vari cercano di convincermi che "e' cosė che si fa software nel ventunesimo secolo".

Sono un po' meno d'accordo circa la critica verso la programmazione ad oggetti, visto che non solo programmo ad oggetti, bensi' lavoro addirittura con gli ODBMS quando in fase di analisi e' palese che il modello di dati ha ordini di gerarchia ed ereditarieta' tali, che gestirli con il relazionale e' da ingenui.

--
Alex


Angkarn@ Alex By Angkarn - posted 28/09/2009 13:07

> Sono un po' meno d'accordo circa la critica verso la programmazione ad oggetti, visto che non solo programmo ad oggetti, bensi' lavoro addirittura con gli ODBMS quando in fase di analisi e' palese che il modello di dati ha ordini di gerarchia ed ereditarieta' tali, che gestirli con il relazionale e' da ingenui.
>

Concordo, trovo che la OOP, se si sa usare è l'approggio giusto per la programmazione di qualcosa di complesso. Ma serve misura, come in tutte le cose. Sennò poi ci si trova con diecimila classi e tremila interfacce per fare più o meno la medesima cosa (elementare).

--
Angkarn


YakkyLa vera coglionaggine... By Yakky - posted 28/09/2009 11:54

... sta nel voler applicare rigidamente l'unica buzzord che si conosce a qualunque problema.
In determinati contesti e con determinati gruppi di lavoro l'Agile Programming funziona, in molti ambiti la OOP è un'ottima soluzione, ma quando ti viene chiesto di correggere 4/8/10 bug in un'applicazione non puoi dire: "Si però gli Unittest di qui, e il CoreCoding di là": correggi quei foxxuti bug e stai zitto.

--
Yakky


Giorgio SironiTDD By Giorgio Sironi - posted 28/09/2009 12:40

Kudos per Yakky. Mi sconcerta vedere quante persone insultino il pair programming, lo unit testing, il refactoring.
I test si scrivono prima del codice perché a) cosė si è sicuri che falliscano nel caso il codice regredisca e b) perché cosė si è sicuri che il codice in produzione sia testabile. E codice testabile significa codice che presente low coupling, quindi riutilizzabile e che facilita la manutenzione. Certe cose sembrino buzzword perché in Italia siamo talmente indietro che non ne esiste ancora una traduzione molto diffusa (test delle unità e basso accoppiamento non mi suonano molto bene). Testing automatico non è difficile da comprendere, significa avere uno strumento per far testare a una macchina mille funzionalità invece che aprire un'applicazione e farlo a mano.
Quando usate google per cercare qualcosa, ricordatevi che loro usano TDD: http://googletesting.blogspot.com/

--
Giorgio Sironi


Alex@ Giorgio Sironi By Alex - posted 28/09/2009 15:30

> Quando usate google per cercare qualcosa, ricordatevi che loro usano TDD:

Anche Vista e' stato sviluppato con il Test-Driven Programming.

--
Alex


Andrea@ Alex By Andrea - posted 28/09/2009 15:54

> Anche Vista e' stato sviluppato con il Test-Driven Programming.

E con ottimi risultati direi! ;\)

--
Andrea


Davide Inglima@ Alex By Davide Inglima - posted 28/09/2009 16:24

>> Quando usate google per cercare qualcosa, ricordatevi che loro usano TDD:

> Anche Vista e' stato sviluppato con il Test-Driven Programming.

Ok, hai qualche link a suffragio di questo?

Grazie.

--
http://limacat.blogspot.com


FDG@ Test scettici By FDG - posted 28/09/2009 16:13

Con un martello puoi ottenere risultati diversi: ci puoi piantare un chiodo o te lo puoi dare in testa. Vuoi dire che dobbiamo buttare il martello? No, affatto! Una bella martellata in testa a volte è risolutiva! :\)

Scherzi a parte, il problema non è lo strumento ma chi lo usa. C'è gente che si nutre di parole ma non capisce un tubo.

--
FDG


Riccardo Cagnasso@ FDG By Riccardo Cagnasso - posted 28/09/2009 22:40

> Con un martello puoi ottenere risultati diversi: ci puoi piantare un chiodo o te lo puoi dare in testa. Vuoi dire che dobbiamo buttare il martello? No, affatto! Una bella martellata in testa a volte è risolutiva! :\)
>
> Scherzi a parte, il problema non è lo strumento ma chi lo usa. C'è gente che si nutre di parole ma non capisce un tubo.
>
Come non concordare?

Il problema e' che le varie "tecniche avanzate di sviluppo del software" hanno un senso se chi le applica e' gia' bravo con le "tecniche base" non si se mi spiego...

--
Riccardo Cagnasso


Luca BG@ FDG By Luca BG - posted 29/09/2009 10:30

> Scherzi a parte, il problema non è lo strumento ma chi lo usa.

Quello è secondo me uno dei problemi. L'altro è l'utilizzo degli strumenti giusti per il problema da affrontare. Se devi fare un pezzo meccanico complicato, usi un tornio a controllo numerico, ma magari per togliere due sbavature al pezzo finito fai prima e meglio con una lima... Qui, idem: quello che può andare bene per un progetto ad ampio respiro e di notevole complicazione, può essere un pochettinino "overkill" per eliminare 4 bug (per valori molto grandi di 4...)

--
Luca BG


Davide InglimaGli idioot si aggrappano a tutto. By Davide Inglima - posted 28/09/2009 16:29

Come da oggetto, non importa quale la combinazione di pantone e profumo, quando hanno voglia di colorare la loro cazzata per coprire la loro incapacità gli idioot si aggrappano a tutto, anche a cose che potrebbero funzionare (in mano altrui).

Detto questo, per esperienza personale TDD ho trovato che funziona, e fra rendermi odioso e inviso a tutto lo staff per rendere TDD obbligatorio e fare le 4 del mattino per trovare il bug inserito dallo stagista/conslutante/professionista/creatore del megaframework che se ne é andato per lidi migliori preferirei rendermi odioso a tutti ed usare TDD. :\)

--
http://limacat.blogspot.com


EarwigAgile Programming, sintomatologia By Earwig - posted 28/09/2009 17:43

direi che FDG ha centrato il problema...

L'Agile Programming (o almeno alcuni dei suoi dettami) POTREBBE essere una bella cosa(non per me, ma se si ha la predilezione verso il masochismo...): il problema e' che, soprattutto in italia, non funzionera' nel 99% dei casi.

Questo per un motivo semplicissimo: il primo presupposto dell' AP consiste nel fatto che il cliente (o chi ne fa le veci, tipicamente un project manager) si trovi "sul campo" a lavorare fianco a fianco con il programmatore.
Peccato che in un paese dove il 99% di questi individui si autoconvincono che per fare il proprio lavoro basti saper scimmiottare lo slang di $famosadittadiconsulenzaglobalemassiccia&incazzata...questo non avverra' mai o quasi.

--
Earwig


VerzasoftSono un programmatore... By Verzasoft - posted 29/09/2009 01:16

...è normale che non ho capito una singola parola di tutta questa pagina?? Ero convinto che il codice si scrivesse in una maniera sola...

--
Verzasoft


Davide Bianchi@ Verzasoft By Davide Bianchi - posted 29/09/2009 08:41

> Ero convinto che il codice si scrivesse in una maniera sola...

Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.

--
Davide Bianchi


Sandra@ Davide Bianchi By Sandra - posted 29/09/2009 10:52

> > Ero convinto che il codice si scrivesse in una maniera sola...
>
> Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.

Uhhh! I paroloni! Che bella cosa!!!
Avvenne in Italia. Richiedo a un grafico "Tesoro, potresti disegnarmi un'iconcina per la tale funzione?" "Nessun problema, dammi una deadline". Sono rimasta basita, ho preso in mano (si fa per dire) wikipedia e ho fatto una ricerca. "Dė, ma sei scemo?!? In Italia ESISTE l'espressione data_di_scadenza, sai? Puoi usarla, non c'è una legge specifica che lo vieti!".
A parte ciò sono programmatore di vecchia data, ho iniziato sul buon vecchio Clipper (ho ancora i dischi!!!) e il caro Oracle e col tempo sono rimasta affezionata al tipo di programmazione. E di sicuro sono rimasta affezionata al sistema: analisi - sviluppo - test!
Ma magari sono io strana!

--
Sandra


Davide Bianchi@ Sandra By Davide Bianchi - posted 29/09/2009 12:40

> "Nessun problema, dammi una deadline".

Che e' successo a "per quando la vuoi"?

> A parte ciò sono programmatore di vecchia data, ho iniziato sul buon vecchio Clipper

CLIPPER! Quanti ricordi! Versione '87 o 5.x?

> Ma magari sono io strana!

Sei in buona compagnia.

--
Davide Bianchi


Alex@ Davide Bianchi By Alex - posted 29/09/2009 13:34

>>E di sicuro sono rimasta affezionata al sistema: analisi - sviluppo - test!

No, ora la moda e': test - sviluppo - analisi - refactoring

E' come dire:

1. costruiamo le poltrone di forma a piacere
2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
3. chiediamo ai clienti se si sentono comodi
4. in caso di risposta negativa, ripetere il ciclo

>>Ma magari sono io strana!
> Sei in buona compagnia.

Aggiungetemi pure alla lista.

Per quanto riguarda la storia che Vista e' stato sviluppato con il TDD, chiedo venia: ricordavo male l'ho letto 4 anni fa. E' stato sviluppato con gli Automated Tests, il che non vuol (necessariamente) dire che i test li abbiano scritti prima del codice.
Va detto tuttavia che se un test scritto con il senno di poi non garantisce la funzionalita' di un componente, per me non la garantisce neanche uno scritto alla cieca.

--
Alex


Adriano@ Alex By Adriano - posted 29/09/2009 14:27

> No, ora la moda e': test - sviluppo - analisi - refactoring
>
> E' come dire:
>
> 1. costruiamo le poltrone di forma a piacere
> 2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
> 3. chiediamo ai clienti se si sentono comodi
> 4. in caso di risposta negativa, ripetere il ciclo

Sarò io, ma comunque quei test iniziali mi sembrava fossero fatti seguendo un'analisi iniziale, per piccolo che sia. Se la tua ditta immagina un progetto TDD cosė, probabilmente è una di quelle a cui si fa riferimento nell'articolo sui soldi pubblicato qui.

Ci sono diversi problemi col TDD, come ad esempio il fatto che i test coprono il programmabile, e che c'è molta funzionalità e usabilità che non è esaminabile con unit tests. Quello citato non è uno. Č un problema dell'essere idioti, non di usare TDD.

--
Saludos
Adriano


Alex@ Adriano By Alex - posted 30/09/2009 10:22

> Se la tua ditta immagina un progetto TDD cosė, probabilmente è una di quelle a cui si fa riferimento nell'articolo sui soldi pubblicato qui.

Diciamo che cerco proprio di non immaginarmela, ho sempre gestito i miei team con RUP e, come dice il buon Davide, con la testa.
Oggigiorno la vera minaccia alla riuscita di un progetto e' la mancanza di professionalita' delle persone coinvolte (project managers, analisti, progettisti, sviluppatori, testers). Recentemente si e' diffuso il concetto TOTALMENTE SBAGLIATO che non importa se chi lavora sia skillato o meno. E Agile e' un invito ad andare in questa direzione, per questo non mi piace: io voglio lavorare con gente competente, non con sedicenti architects con 2 anni di esperienza in sviluppo e un attestato di partecipazione ad un seminario di Scrum. In compenso piace ai manager perche' li si illude di poter risparmiare sulle risorse.

--
Alex


Anonymous cobra@ Alex By Anonymous cobra - posted 30/09/2009 12:12

> >>E di sicuro sono rimasta affezionata al sistema: analisi - sviluppo - test!

si chiama waterfall (mai sentito il corrispondente "a cascata"). in progetti rognosi quando hai finito analisi e sviluppo, le specifiche sono cambiate: l'applicazione va benissimo ma non serve piu'. inoltre non riesci a reagire ai cambiamenti in modo veloce: tutto diventa una comunicazione tra fornitore e cliente.

> No, ora la moda e': test - sviluppo - analisi - refactoring

che confusione! mescoli TDP e generico agile...

> E' come dire:
>
> 1. costruiamo le poltrone di forma a piacere
> 2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
> 3. chiediamo ai clienti se si sentono comodi
> 4. in caso di risposta negativa, ripetere il ciclo

no. in teoria (ma non essendo nemmeno io un fan del TDP potrei sbagliarmi)
1. crea un modello di cuscino, schienale etc..
2. prepara un test per vedere se sono comodi
3. applica 2 ad 1 fino a che va bene
4. fai provare al cliente.

>
> >>Ma magari sono io strana!

vorrei vedere come vai al supermarket o compri i vestiti: progetti tutto prima di entrare in negozio e compri come da lista della spesa o provi quello che ti sembra bene e ti guardi allo specchio? comprare spaghetti o un abito e' un progetto diverso e non usi lo stesso processo

> > Sei in buona compagnia.
>
> Aggiungetemi pure alla lista.



> Per quanto riguarda la storia che Vista e' stato sviluppato con il TDD, chiedo venia: ricordavo male l'ho letto 4 anni fa. E' stato sviluppato con gli Automated Tests, il che non vuol (necessariamente) dire che i test li abbiano scritti prima del codice.
> Va detto tuttavia che se un test scritto con il senno di poi non garantisce la funzionalita' di un componente, per me non la garantisce neanche uno scritto alla cieca.


Fammi capire: tu sviluppi una funzione senza sapere quello che deve fare?

--
Anonymous cobra


Davide Bianchi@ Anonymous cobra By Davide Bianchi - posted 30/09/2009 12:17

> no. in teoria (ma non essendo nemmeno io un fan del TDP potrei sbagliarmi)
> 1. crea un modello di cuscino, schienale etc..
> 2. prepara un test per vedere se sono comodi
> 3. applica 2 ad 1 fino a che va bene
> 4. fai provare al cliente.

Ottimo. E che e' successo al buon-vecchio "misura il culo del cliente e fai il cuscino giusto la prima volta"?
Che in termini informatici significa "interroga il cliente, scrivi le specifiche e fai il programma in funzione di quelle".

--
Davide Bianchi


Alex@ Davide Bianchi By Alex - posted 30/09/2009 12:42

> Che in termini informatici significa "interroga il cliente, scrivi le specifiche e fai il programma in funzione di quelle".

D'accordissimo con te, ma questo succede se: o il cliente ha le idee chiare, o l'analista funzionale che interroga il cliente ha le idee chiare.

Se entrambi sono ex programmatori che hanno ricevuto la promozione perche' erano delle scamorze e piuttosto che fargli scrivere codice e' meglio fargli fare i project manager... allora la vedo dura che il buon vecchio metodo funzioni: non funzionera' ne' Agile, ne' RUP. E qui mi riaggancio al discorso che gli attori del panorama informatico d'oggigiorno non sono piu' Al Pacino e Robert de Niro, ma Scamarcio e Muccino.

--
Alex


Anonymous coward@ Alex By Anonymous coward - posted 30/09/2009 14:39

> Se entrambi sono ex programmatori che hanno ricevuto la promozione perche' erano delle scamorze e piuttosto che fargli scrivere codice e' meglio fargli fare i project manager... allora la vedo dura che il buon vecchio metodo funzioni: non funzionera' ne' Agile, ne' RUP.

Ok, a questo punto sono curioso del perchè l'Agile Programming incoraggi i code monkeys. Semmai, direi che affiancare (nel pair-programming) un'esperto a un novellino sarebbe benefico per la qualità del codice e per il novellino. Pure l'imparare a scrivere test non sembra troppo controproducente. Spiegheresti cosa intendevi?

--
Anonymous coward


Alex@ Anonymous coward By Alex - posted 30/09/2009 16:38

> Ok, a questo punto sono curioso del perchè l'Agile Programming incoraggi i code monkeys

Sei a favore dell'Agile e a quanto pare dell'XP. Di conseguenza hai una visione code-centrica di tutto il processo. Nel processo di produzione di soluzioni software enterprise non esiste solo il codice del programma e il codice dei test. Esistono lo studio di fattibilita, l'analisi funzionale, l'analisi tecnica, la progettazione e solo alla fine lo sviluppo, i test funzionali, i test di carico e i test di accettazione (UAT).
Agile promette di poter fare come i gamberi, partire dal risultato e, dando un colpo al cerchio e uno alla botte, far funzionare il tutto. Semplicemente come processo non mi soddisfa, in progetti piccoli può anche funzionare, se devo fare un sitarello di 10 pagine mica mi metto a disegnare i diagrammi di Gantt per coordinare le risorse. Prendo un junior gli faccio buttare giu' il codice e lo seguo per vedere se sta facendo giusto.
In progetti veramente grandi ti assicuro che non conviene neanche provarci: o si ha le idee chiare su cosa si vuole fare, o la teoria dell'Emerging Design te la puoi scordare. Insomma, stando alla mia esperienza personale, quando si parla di Software Engineering, Darwin ha torto.

O forse ho torto io. Boh.

--
Alex


Adriano@ Alex By Adriano - posted 30/09/2009 18:02

> Sei a favore dell'Agile e a quanto pare dell'XP. Di conseguenza hai una visione code-centrica di tutto il processo.

Ma anche no. Non ho ancora usato mai Agile o XP (difficile fare pair programming essendo un solo programmatore). Ma tra quello che dicono, se uno legge attentamente, e le tue critiche, trovo un pò di differenza. In loro favore, mi pare si sia capito. Affiancare un esperto a un novellino forse toglie tempo all'esperto, vero, ma mi pare in teoria un eccellente metodo di addestrare qualcuno, di programmare facendo che tutti conoscano il codice del progetto, di avere una buona seconda opinione, o di disfarsi di una zavorra velocemente. Dipende dai caratteri dei programmatori affiancati, però.

> Nel processo di produzione di soluzioni software enterprise non esiste solo il codice del programma e il codice dei test. Esistono lo studio di fattibilita, l'analisi funzionale, l'analisi tecnica, la progettazione e solo alla fine lo sviluppo, i test funzionali, i test di carico e i test di accettazione (UAT).

D'accordissimo, ma mi sa che questi ci sono anche nell'Agile, o almeno, in quello che userei io. Come ho già detto prima, almeno. I test unitari, da quanto ho capito, sono:
- basati su uno studio di cosa si deve fare
- progettati per essere il più piccoli possibile ciascuno
- non un 'adesso faccio i test e poi è tutto pronto', che leggo solo dai detrattori.

> Agile promette di poter fare come i gamberi, partire dal risultato e, dando un colpo al cerchio e uno alla botte, far funzionare il tutto. Semplicemente come processo non mi soddisfa, in progetti piccoli può anche funzionare, se devo fare un sitarello di 10 pagine mica mi metto a disegnare i diagrammi di Gantt per coordinare le risorse. Prendo un junior gli faccio buttare giu' il codice e lo seguo per vedere se sta facendo giusto.

Per questi piccoli progetti non ti serve neanche Agile, mi sa, fallo velocemente e basta.

> In progetti veramente grandi ti assicuro che non conviene neanche provarci: o si ha le idee chiare su cosa si vuole fare, o la teoria dell'Emerging Design te la puoi scordare. Insomma, stando alla mia esperienza personale, quando si parla di Software Engineering, Darwin ha torto.
>
> O forse ho torto io. Boh.

Da quanto leggo sopra, almeno quelli di Google sembrano trarne giovamento. Boh. Devo anche dire che ci sono un sacco di programmatori che giurano su almeno alcuno dei princėpi dell' AP. Come altri che no. Io... Io uso quello che posso.

--
Saludos
Adriano


Alex@ Adriano By Alex - posted 30/09/2009 18:34

> Da quanto leggo sopra, almeno quelli di Google sembrano trarne giovamento.

Beh, non e' perche' funziona in un caso (e che caso scusa...) che cambio idea.
O mi dimostrate che mi cambia radicalmente la vita in meglio o continuo a gestire i progetti come ho sempre fatto.

> Per questi piccoli progetti non ti serve neanche Agile, mi sa, fallo velocemente e basta.

Ed e' esattamente questo il punto. Per progetti grossi Agile non funziona, per quelli piccoli non vale la pena usare alcun processo particolare.

Anticipo gia' la prossima obiezione: e allora perche' li hanno inventati?

Ma mi sembra ovvio. Chi ci ha veramente guadagnato da tutta questa storia sono quelli che tengono le conferenze, che scrivono libri, che insegnano ai seminari e che ti vendono la certificazione facendoti credere che ora hai le palle di adamantio.
Quando la gente capira' che sotto-sotto Agile non serve si inventeranno qualcos'altro e te la spacceranno per il nuovo Santo Graal che risolvera' tutti i tuoi problemi, il libro comincera' cosi':

"Nello scorso decennio l'approccio allo sviluppo software ha seguito la filosofia Agile. Sebbene le premesse fossero incoraggianti, l'esperienza ha dimostrato come valore aggiunto di tale metodologia fosse poco se non addirittura nullo."

Seriamente: questo weekend lasciate perdere l'informatica, le classi, le interfacce e studiate un po' di marketing, ad esempio Il Bisogno Indotto.

--
Alex


Adriano@ Alex By Adriano - posted 01/10/2009 19:56

> O mi dimostrate che mi cambia radicalmente la vita in meglio o continuo a gestire i progetti come ho sempre fatto.

E perchè dovrei? Se ti va di informarti, e trarre giovamento dai punti validi dell'Agile Programming, dei test, ecc, buon per te, ma se no, non starò mica a rimbeccarti... Non sono un venditore del processo, mi pare solo che abbia qualche buona idea dentro.

> Ed e' esattamente questo il punto. Per progetti grossi Agile non funziona, per quelli piccoli non vale la pena usare alcun processo particolare.
>
> Anticipo gia' la prossima obiezione: e allora perche' li hanno inventati?

E sbagli. L'obiezione è 'lo dici tu che non funziona'. Mi piacerebbe più evidenza di questo. Come a te piacerebbe più evidenza del fatto che funzioni. La piccola differenza è che a me interessa sapere se le parti che mi interessano funzionano, e quando; e non ho bisogno di acquistare o buttare tutto il pacchetto.

--
Saludos
Adriano


Alex@ Adriano By Alex - posted 01/10/2009 21:46

> E sbagli. L'obiezione è 'lo dici tu che non funziona'. Mi piacerebbe più evidenza di questo.

http://www.softwaremetrics.com/Agile/Agile%20Method%20and%20Other%20Fairy%20Tales.pdf

La cosa interessante e' che l'ho trovato oggi, e dice le stesse cose che dico io da 8 anni. Mi piace in particolare dove afferma che Agile "formalizza le cattive abitudini".
Quindi, visto che sono per l'OO e per il riutilizzo del codice, non riscrivero' cose gia' scritte da qualcun'altro meglio di come le scriverei io.

--
Alex


Adriano@ Alex By Adriano - posted 02/10/2009 14:18

> > E sbagli. L'obiezione è 'lo dici tu che non funziona'. Mi piacerebbe più evidenza di questo.
>
> http://www.softwaremetrics.com/Agile/Agile%20Method%20and%20Other%20Fairy%20Tales.pdf
>
> La cosa interessante e' che l'ho trovato oggi, e dice le stesse cose che dico io da 8 anni. Mi piace in particolare dove afferma che Agile "formalizza le cattive abitudini".
> Quindi, visto che sono per l'OO e per il riutilizzo del codice, non riscrivero' cose gia' scritte da qualcun'altro meglio di come le scriverei io.
>

Ho trovato tanti aneddoti in quel whitepaper che ho chiuso alla decima pagina. Bellissimo come dice di essere uno statistico (e ci credo), ma non c'è uno straccio di studio nella prima metà del paper. Ti lascio questo link, tanto per ricambiare: http://stackoverflow.com/questions/301993/is-agile-development-dead

E chiudo qua, perchè ormai mi hai stufato. Se senti e leggi solo quello che vuoi sentire, buon pro ti faccia.

--
Saludos
Adriano


Alex@ Adriano By Alex - posted 03/10/2009 13:54

> Ho trovato tanti aneddoti in quel whitepaper che ho chiuso alla decima pagina.
> Bellissimo come dice di essere uno statistico (e ci credo), ma non c'è uno straccio di studio nella prima metà del paper.

Venti pagine... madonna santa che fatica. Ti faccio un riassunto.

Dice che il problema dell'informatica sono gli informatici stessi. Vogliono arrivare troppo presto al sodo (schiacciare bottoni) perche' e' l'unica cosa che sanno fare e non necessariamente bene. Una specie di ejaculazione precoce in salsa informatica, zero preliminari e risultati miseri quando e' ora.
E' risaputo che gli informatici medi sono incapaci di relazionarsi con le persone, in questo caso: raccogliere requisiti ben fatti presso il cliente.

Agile fa presa sulle masse perche' formalizza la cattiva abitudine di ritenere l'informatica al centro dell'universo, mentre i clienti sono dei poveri ebeti che non sanno fornire correttamente le specifiche di un progetto. La verita' e' che sono gli informatici a non saperle raccogliere. Piuttosto che ammettere che l'informatica e' una scienza giovane che ha ancora molto da imparare, Agile preferisce dire che sono gli altri ad essere dei vecchi rimbambiti e quindi devono cambiare loro, le cattive abitudini dell'informatica e tutti i suoi capricci devono rimanere come sono.

Io personalmente vedo Agile come l'adolescenza dell'informatica, la fase di ribellione dove si pensa di avere sempre ragione. E' un passaggio obbligato. Dura ancora un po' e poi, speriamo, diventera' adulta e incomincera' ad assumersi le proprie responsabilita'.

P.S. Questo era solo un paper. L'autore ha scritto un libro descrivendo piu' ampiamente le sue idee, non ti giro il link perche' ora mi sono stufato io.

--
Alex


Davide Bianchi@ Alex By Davide Bianchi - posted 04/10/2009 08:36

> Dice che il problema dell'informatica sono gli informatici stessi.

Sostituisci "informatica" ed "informatici" con "programmazione" e "programmatori"

--
Davide Bianchi


Anonymous cougar@ Davide Bianchi By Anonymous cougar - posted 01/10/2009 10:37

> Ottimo. E che e' successo al buon-vecchio "misura il culo del cliente e fai il cuscino giusto la prima volta"?

e' successo che l'azienda ha assunto talmente tanti manager e bisniss anal-ists per produrre carta inutile e ritardi nel processo che il tuo cliente ha preso 20 chili tra la commessa e la consegna ed il suo culo non ci sta piu'. ah, il cliente nel frattempo si e' sposato e vuole un divano. no, non piu' nero, la moglie lo vuole a fiori.

--
Anonymous cougar


Alex@ Anonymous cobra By Alex - posted 30/09/2009 12:33

> no. in teoria (ma non essendo nemmeno io un fan del TDP potrei sbagliarmi)
> 1. crea un modello di cuscino, schienale etc..
> 2. prepara un test per vedere se sono comodi
> 3. applica 2 ad 1 fino a che va bene
> 4. fai provare al cliente.

Questo non e' test-driven. Qui stai scrivendo il codice prima e i test poi e nel mio caso sfondi una porta aperta: non sono contrario ai test ci mancherebbe. Voglio solo evidenziare il paradosso temporale del disegnare prima i test e scrivere l'applicazione in seguito per non farli fallire.

TDD e' piuttosto:

1. farle fare il test di gravidanza (test)
2. ehm... ok ci siamo capiti (development)
3. chiedere alla ragazza se ci sta (analisi)

--
Alex


Sandra@ Davide Bianchi By Sandra - posted 29/09/2009 21:23

> > A parte ciò sono programmatore di vecchia data, ho iniziato sul buon vecchio Clipper
> CLIPPER! Quanti ricordi! Versione '87 o 5.x?

Bè, ho iniziato con una roba che chissà se qualcuna se la ricorda; si chiamava KnowledgeMan, era un sistema integrato con dbms relazionale (l'alternativa era Focus, reticolare. Che casino!!!). Poi db3, poi clipper 87 e in parallelo Oracle e poi via cosė. Ai giorni nostri uso Visual Foxpro (e lo uso come fosse Clipper! fregandomene dell'object oriented per quanto possibile) e poi... lo so, mi vergogno e chiedo scusissima....... PHP e MySql per il web! Uah Uah Uah!!!

--
Sandra


IgorB@ Davide Bianchi By IgorB - posted 29/09/2009 15:30

> > Ero convinto che il codice si scrivesse in una maniera sola...
>
> Si', si scrive con la testa, [...]

Questa è la Grande Verità, di cui sono adepto, pur scrivendo al massimo un po' di SQL!

--
IgorB


Sabrina@ Davide Bianchi By Sabrina - posted 13/10/2009 19:16

> > Ero convinto che il codice si scrivesse in una maniera sola...
>
> Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.

Questa e' una frase bellissima, quando e se dovessi diventare programmatrice ci farei un quadretto da appendere in ufficio.

--
Sabrina


Andrea OcchiAgile programming By Andrea Occhi - posted 29/09/2009 08:47

Purtroppo troppe volte Agile Programming viene visto solo come un modo di ritardare la consegna delle specifiche, senza dare il tempo di fare tutta la metodologia.
A questo punto tutto va a donnine di facili costumi....

--
Andrea Occhi


Anonymous coderla differenza tra riparare e creare By Anonymous coder - posted 29/09/2009 09:32

per quanto ci siano un sacco di persone che parlano a vuoto, spesso le tecniche di design piu' "moderne" sono valide. sta nell'intelligenza delle persone di scegiere l'approccio giusto a seconda del problema. uno come martin fowler, ad esempio, non e' un venditore di fumo. non nel caso della storia pero' siamo ancora in un'altra categoria: un conto e' un lavoro per fare un programma da zero, un conto e' fare del bugfix.

--
Anonymous coder


Alex@ Anonymous coder By Alex - posted 30/09/2009 11:57

> uno come martin fowler, ad esempio, non e' un venditore di fumo.

No, e' un venditore di libri. Lui il suo obiettivo l'ha raggiunto.

P.S. A scanso d'equivoci, non sono a priori contro tutto quello che Fowler afferma.

--
Alex


Anonymous coward@ Alex By Anonymous coward - posted 01/10/2009 10:50

> > uno come martin fowler, ad esempio, non e' un venditore di fumo.
>
> No, e' un venditore di libri.

LOL. ma sai che sta facendo ora?

--
Anonymous coward


EstrandalMi devo preoccupare? By Estrandal - posted 29/09/2009 10:29

E' un pò OT lo sò ma...
Ultimamente la mia società vuole fare una "Intranet" e le persone che se ne occupano mi danno la fiducia di un venditore di paralumi...
Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
Leggendo una tua vecchia storia mi viene un dubbio.
Mi devo preoccupare?

--
Estrandal


Adriano@ Estrandal By Adriano - posted 29/09/2009 14:22

> Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
> Leggendo una tua vecchia storia mi viene un dubbio.
> Mi devo preoccupare?

Non lo sei già?

--
Saludos
Adriano


Anonymous coward@ Estrandal By Anonymous coward - posted 30/09/2009 08:12


> Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
> Leggendo una tua vecchia storia mi viene un dubbio.
> Mi devo preoccupare?

Ma nooo. E' sufficiente che migriate tutto quello che fate a qualcosa che gestisca LDAP in modo nativo e trasparente, cosi' che non ci sia bisogno di capire come cappero funziona.
Hai presente, no: "avanti, avanti, ok, avanti, seleziona, avanti, ok, fine".

Ehm... Cosi', giusto per curiosita'... Che differenza passa tra "posta elettronica" ed "email", li' da voi?

CYA

--
Anonymous coward


Anonymous coward@ Anonymous coward By Anonymous coward - posted 30/09/2009 12:04

>
> > Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
> > Leggendo una tua vecchia storia mi viene un dubbio.
> > Mi devo preoccupare?
>
> Ma nooo. E' sufficiente che migriate tutto quello che fate a qualcosa che gestisca LDAP in modo nativo e trasparente, cosi' che non ci sia bisogno di capire come cappero funziona.
> Hai presente, no: "avanti, avanti, ok, avanti, seleziona, avanti, ok, fine".
>
> Ehm... Cosi', giusto per curiosita'... Che differenza passa tra "posta elettronica" ed "email", li' da voi?
>
> CYA
>
Volevo dire tra account di dominio e posta elettronica...
E ho scritto anche elettrionica (horrore...)
Vista le mie gaffes penso di essere già preoccupato a livello inconscio ^^

--
Anonymous coward


VerzasoftChi č che mi gufa contro? By Verzasoft - posted 30/09/2009 11:00

Solo due giorni fa ho scritto "non so di cosa state parlando".
Ieri cos'è successo! Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.
In pratica, ora credo di poter riassumere in cosa consiste questo agile programming:
1) fare le stesse cose di prima, con un metodo comune (comune a chi? per ogni divisione sw siamo in due!), imposto, difficile da applicare e in ogni caso temporalmente dispendioso.
2) Loggare ogni azione che viene eseguita durante la giornata di modo da poter avere una piena conoscenza di cosa si ha fatto. Poco importa che metà del tempo sia stato usato per creare il log. (Ah! Il falso mito che avere un log delle azioni di un programmatore equivalga ad avere il controllo della situazione)
3) Usare il forum anzichè chiedere lumi direttamente al collega a fianco che ha fatto lui il programma, perchè cosi' tutti gli altri potranno vedere la risposta (l'ho già detto che i settori sono di DUE persone?). Poi voglio vedere quanto ci metto a risolvere un problema via forum (costiturà la nostra knowledge-base!) e quanto parlando col collega di fianco...
4) Il "repository comune". Cos'ha la nostra directory condivisa sul server che non va?

Ho indovinato?

--
Verzasoft


Davide Bianchi@ Verzasoft By Davide Bianchi - posted 30/09/2009 11:08

> Ieri cos'è successo! Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.
...
> Ho indovinato?

Povero te... tu non hai idea... Aspetto le storie eh...

--
Davide Bianchi


maxxfi@ Verzasoft By maxxfi - posted 30/09/2009 13:49


> Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.
E gia' cosi' sono partiti col piede sbagliato. Se lo imponi dall'alto senza
farlo capire a tutti prima, qualunque metodo fallira'.

Io ho lavorato per un paio di anni con progetti agile, e non mi pare che i punti 2 e 3 facevano parte del programma, anzi. P.es. gli sviluppatori venivano riorganizzati in modo da essere fisicamente vicini tra di loro, in modo da aiutarsi a vicenda, senza loggare nulla o perdere tempo a scrivere su forum o email.

Poi certo c'erano forum, sistemi di IM e wiki varie, ma era per lasciare traccia a chi veniva dopo (uno dei criteri era scrivere MENO documentazione inutile e perder MENO tempo con meeting lunghi)


--
maxxfi


Davide Bianchi@ maxxfi By Davide Bianchi - posted 30/09/2009 14:00

> Poi certo c'erano forum, sistemi di IM e wiki varie, ma era per lasciare traccia a chi veniva dopo (uno dei criteri era scrivere MENO documentazione inutile e perder MENO tempo con meeting lunghi)

Peccato che, di solito, il punto uno (meno documentazione) viene raggiunto perfettamente: non si scrive piu' documentazione alcuna, il punto due invece...

--
Davide Bianchi


Alex@ Davide Bianchi By Alex - posted 30/09/2009 14:36

> Peccato che, di solito, il punto uno (meno documentazione) viene raggiunto perfettamente: non si scrive piu' documentazione alcuna, il punto due invece...

Ah, gia'... un'altra perla e': non si scrivono commenti, il codice e' autoesplicante.

--
Alex


Earwig@ Verzasoft By Earwig - posted 30/09/2009 20:58

> Ieri cos'è successo! Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.

MWAHAHAHAHAH, povero te...hai tutta la mia solidarieta'.
Comunque non si tratta ne' di gufata, ne di Murphy: semplicemente e' la nuova moda, inizia a spuntare come i funghi dappertutto.

Soprattutto perche' consente agli UL strapagati(e completamente incapaci) di fingere molto meglio di far parte del progetto, e che il lavoro non lo fanno SOLO i programmatori: ma soprattutto, gli permette di stare tutta la giornata appolaiati come gufi dietro la tua schiena, dicendoti cosa fare ogni minuto senza "sprecare tempo" nelle vecchie, lunghe, inutili analisi funzionali che la vecchia metodologia imponeva(e che toccava fare a loro...e che di solito costituiva prova fisica della loro incapacita').

Oh, leggete qui sopra tenendo a mente che sono tremendamente sarcastico eh !!!!

> 1) fare le stesse cose di prima, con un metodo comune ...

in 2 persone fate anche gli Scram ? :D

> 2) Loggare ogni azione che viene eseguita durante la giornata....
a me avevano imposto un foglio Excel per "loggare"...uno nuovo ogni 2 settimane.

Non ti dico quando bisognava creare il nuovo "Backlog"...2 giorni persi: tutti e 6 gli sviluppatori fermi a discutere su cosa inserirci e scrutando nella sfera di cristallo la risposta a "quanti giorni ci si mette a fare questo pezzettino ?" (giuro che sembrava di essere ad un'asta, ma con il numero di ORE che scendeva, non saliva ).

> 3) Usare il forum anzichè chiedere lumi direttamente al collega a fianco....

questo veramente dovrebbe essere l'opposto delle metodologie agili eh....dato il fatto che ogni task deve essere spezzettato in subtask della dimensione di un atomo, in teoria si dovrebbe PARLARE ogni 2 secondi per coordinarsi.

> 4) Il "repository comune". Cos'ha la nostra directory condivisa sul server che non va?

vabbeh dai...questa non te la passo. un SCM e' cento volte piu comodo di una "directory comune", e' supportato dagli IDE, se fai caxxate puoi tornare indietro, puoi creare le TAG per stabilire punti stabili del codice, ecc...

--
Earwig


Verzasoft@ Earwig By Verzasoft - posted 01/10/2009 09:07

> in 2 persone fate anche gli Scram ?
ESATTO!! :\) Vedo che tu SAI! :\)

Il bello è che l'UL in questione è una persona giovane e competente, mica un pizzettaro, per quello mi sono stra-stupito quando se n'è uscito con questa storia.

--
Verzasoft


Anonymous coward@ Verzasoft By Anonymous coward - posted 01/10/2009 16:14

> > in 2 persone fate anche gli Scram ?
> ESATTO!! :\) Vedo che tu SAI! :\)
>
> Il bello è che l'UL in questione è una persona giovane e competente, mica un pizzettaro, per quello mi sono stra-stupito quando se n'è uscito con questa storia.
>
>
Anche chi lo aveva imposto a me e' competentissimo e intelligente...e' solo che:
1) vendersi come "Agile Programmer" e' la novita' del momento: se non "lavori in casa" (aka fai il consulente), e' utilissimo per dimostrare di avere una marcia in piu.
2) e' troppo ottimista riguardo gli UL...gli e' andata bene la prima volta perche' gli UL non avevano mai visto un progetto gestito in quel modo, ma la seconda hanno imparato come approfittarsene ed e' successo il disastro.

--
Anonymous coward


Adriano@ Earwig By Adriano - posted 01/10/2009 15:24

> > 4) Il "repository comune". Cos'ha la nostra directory condivisa sul server che non va?
>
> vabbeh dai...questa non te la passo. un SCM e' cento volte piu comodo di una "directory comune", e' supportato dagli IDE, se fai caxxate puoi tornare indietro, puoi creare le TAG per stabilire punti stabili del codice, ecc...

Anch'io sono favorevolissimo ai VCS. Installare e usare subversion (con tortoisesvn su Windows, pure) è facilissimo, e la quantità di problemi che risolve è enorme. A cominciare da 'Mi hai sovrascritto il file con i cambiamenti, ARGH!'

--
Saludos
Adriano


R.P.come andra' a finire. By R.P. - posted 01/10/2009 08:22

A. il Canadese non risolvera' una cippa di niente, anzi peggiorera' le cose.
B. verrannno presi successivamete un turco, un albanese e un libanese, ognuno dei quali peggiorerà a sua volta la situazione
C. alla fine il padulo finirà, come al solito, tra le chiappe di BigD.
D. BigD cambierà lavoro.

insomma, un film già visto :-\)

--
R.P.


Mauro Pietrobelli@ R.P. By Mauro Pietrobelli - posted 01/10/2009 11:11

> C. alla fine il padulo finirà, come al solito, tra le chiappe di BigD.

Ma perchè vuoi cosė male a DigD?

--
Mamo


Davide Bianchi@ Mauro Pietrobelli By Davide Bianchi - posted 01/10/2009 11:25

> Ma perchè vuoi cosė male a DigD?

Secondo me gode delle mie sofferenze...

--
Davide Bianchi


Anonymous cowardHumm... By Anonymous coward - posted 04/10/2009 11:47

Visto che si discute di metodologie & filosofie di programmazione, my 2c: la maggior parte delle metodologie nasce dall'esperienza di un dato sviluppatore/team su di un dato ambito di progetti, da cui gli autori CERCANO di astrarre un metodo che possa avere una applicabilità più ampia cambiando gli sviluppatori e la tipologia dei progetti.

La chiave è proprio in quel "cercano": per quanto in ogni metodologia ci siano parecchi spunti utili che bene conoscere e soprattutto provare (in prima persona e nella propria realtà), non bisogna pensare che i benefici del metodo si trasmettano automagicamente a qualsiasi altro sviluppatore/team che sta lavorando su progetti magari di tutt'altra natura.

Un metodo che vada bene per scrivere grandioso software aziendale non è in toto applicabile allo sviluppo del software di massa o ai giochi (non li distribuisci a gente che puoi contattare di persona, nè sai che hw/sw hanno installato), e a sua volta metodi ottimali per questi mondi non serviranno a molto per sviluppare il software di controllo per la rom del frigorifero.

Poi, un metodo che vada bene per grandi team di sviluppo non andrà bene per singoli sviluppatori, uno che miri a rendere in fretta produttivi nuovi sviluppatori in un progetto non sarà proprio ideale per un team già affiatato, uno che sia eccellente per incastrare migliaia di attività per una release a lunga schedulazione servirà a poco se magari hai una webapp e devi testare poche update per volta ma in tempo reale, e cosė via...

Però ogni metodo può insegnarci qualcosa, quindi non ha senso corregli troppo dietro a prescindere dall'applicabilità reale, come non ha senso spararci sopra perchè a noi in questo dato contesto serve a poco o addirittura ci fa solo perdere tempo.

--
Anonymous coward


75 messages this document does not accept new posts

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira