Newsgroup: it.lavoro.informatica
Titolo: socio commerciale vs dipendente programmatore

siccome ci sono stati dei problemi e lo sviluppatore(2) sta facendo 
praticamente assistenza ai tecnici (perche' oggi i tecnici bravi son 
tutti in trasferta e son rimasti solo quelli scarsi) uno dei soci (1) si 
incazza:
1: "NON è POSSIBILE CONTINUARE COSI' BISOGNA BLINDARE LE PROCEDURE!NON 
PUOI PERDERE TEMPO!!!"
2: "Non posso prevedere tutto occorre fare dei test!"
1: "NOOOOOOOOOOOOOOOOOOOOOOOO i test! noooooooo!Devi stare piu' attento."
LoL, meglio riderci su!
ps
i problemi erano derivati da una errata configurazione da parte di un 
cliente. Secondo 2 la configurazione non deve essere possibile 
sbagliarla e ci sta anche però essendo molto complessa e rimaneggiata 
piu' volte non credo sia possibile farlo senza essere riprogettata! :-D

 LoL, meglio riderci su!
no, in realtà è una situazione da prendere sul serio. è un
"misunderstanding" assurdo perché una metodologia test-driven costa
sempre meno di di una non-metodologia; se quel socio commerciale non
lo sa è perché nell'azienda non c'è nessun tecnico con sufficiente
autorevolezza che glie lo possa far capire, perché è ovvio se lo
sapesse non avrebbe nulla in contrario.
fintanto i test continueranno ad essere presentati come costi voi
continuerete a non farli, le procedure continueranno ad uscire buggate
e nessuno sarà soddisfatto.

 driven?
i tempi di consegna li sventoli come lo spauracchio ma è una cosa con
la quale ci conviviamo tutti, non è che si lavora a babbo morto. un
team che si dota di una metodologia ha sicuramente molte più
possibilità di rispettare tempi e qualità. certo se mi fai l'esempio
del branco di incapaci capitanati da un altrettanto incapace che detta
le condizioni impossibili è ovvio che non c'è nulla da conciliare, in
quei casi ci si tappa gli orecchi e si aspetta il botto.

 1: "NOOOOOOOOOOOOOOOOOOOOOOOO i test! noooooooo!Devi stare piu' attento."
Sigh... č quello che mi sento dire da sempre, seppure con toni piů "soft"... 
che schifooooooo 

 miei colleghi non sanno nemmeno cosa sono gli unit test
Perché non sono nemmeno junior.
Io uno che non sapesse cosa sono gli unit test, non lo assumerei mai
per sviluppare software.
--
ale
http://ale.riolo.co.uk

 sempre meno di di una non-metodologia; se quel socio commerciale non
Dati ? Studi ? Ricerche ?
o pareri personali ?

 Tu invece temo che sia un classista integralista.
la parola "integralista", scritta da te, fa specie.. è stano come gli 
altri siano integralisti e tu invece no (prima che i tuoi messaggi siano 
eliminati, rileggiti)
S.


Da me, mi mandano a fare in c*lo direttamente, apertamente, 
abbondantemente e qualunquemente.
Se non fosse squallido, oggi dovrei sghignazzare, dato che sono 
settimane che i due 'programmatori-lider' per ogni baco che sistemano ne 
creano altri due in posti che prima funzionavano...

 junior con esperienza pluriennale.
A me invece sembra uno che poi va a 200 euro/ora presso utente finale
per scrivere e condurre test case, onde decidere o meno se teneresi il
software pagare gli sviluppatori o rimandare tutto indietro o
addirittura chiedere i danni (la tariffa internazionale è quella...).

 che schifooooooo
boh cmq ieri non c'era tutto di testa, sarà lo stress o so il ca*** ma 
quel demente e' strippato di brutto anche con me (ci sta anche perdere 
la pazienza ma c'e' modo e modo pd) perche' a suo dire avevo realizzato 
un interfaccia secondo lui non user-friendly (peraltro realizzata 
secondo l'analisi del project-manager ora assente.)!
ps
sperate che il pj non stia mai male altrimenti e' un casino.

 creano altri due in posti che prima funzionavano...
lol spaghetti-code warning! :-D

 Scenari pressoch impossibili in Italia.
Ma come, questormai è la best practice perfino fra le sabbie dei
deserti arabici, e non si pratica nemmeno nell'avanzatissima Milano?
ROTFL!



premesso che io qui esprimo sempre pareri personali, se vogliamo
discutere che costi meno una metodologia piuttosto che un'altra ci
posso stare, ma se contesti il fatto che costi meno avere una
metodologia rispetto a lavorare a braccio allora significa che vuoi
polemizzare a vuoto. nel caso dell'op il fatto che escano delle
procedure buggate è un *costo* sia diretto (i bug laddove si vogliono
risolvere vanno risolti gratis) che indiretto (danno d'immagine che si
ripercuoterà sul prossimo progetto con quel cliente, se ci sarà),
infatti il commerciale se si sta lamentando non è per chissà quali
motivi astratti ma probabilmente perché coi costi stanno sforando il
budget.

 polemizzare a vuoto. nel caso dell'op il fatto che escano delle
Veramente non era una polemica vuota, cioè... era una polemica
ovviamente ma non vuota ! Visto che eri partito bello deciso sulla
validità di una metodologia volevo sottolineare che siamo e restiamo
sulle opinioni personali. L'approccio test driven è a tuo e a parere
di molti altri efficace (che poi il test driven NON è fare test, come
sembra poi emergere dal discorso), ma questi sono appunto pareri.
Mancano studi, o almeno io non ne trovo, ogni tanto esce LA SOLUZIONE,
poi passa la moda.
Sull'adottare una metodologia piuttosto che nessuna mi trovi
ovviamente d'accordo in linea di massima, anche se certe metodologie
sono decisamente peggio di non avere metodologie.

 sono decisamente peggio di non avere metodologie.
per esempio?

 quei casi ci si tappa gli orecchi e si aspetta il botto.
in poche righe ha riepilogato esattamente le circostanze in cui molti 
lavorano da anni. E io aggiungo: in molti scenari e' un alibi per tutti NON 
fare uno straccio di test, altrimenti altro che tempi di consegna :-(

 fare uno straccio di test, altrimenti altro che tempi di consegna :-(
guarda, sono situazioni in cui siamo passati tutti. quando ho
cominciato ad avere la possibilità di spingere verso l'uso di una
metodologia che prevedesse almeno l'uso sistematico degli unit test il
risultato s'è visto, anche in termini di tempi di sviluppo. mi ricordo
anni fa quando subentrai come capo progetto in un gruppo che
sviluppava un gestionale, vedevo che la maggior parte delle volte
tornavano indietro dei bug idioti come sintassi sql sbagliate, o
comunque errori che stavano ad indicare che certe parti di codice
venivano eseguite per la prima volta dal cliente. la giustificazione
per tutti era "ma non abbiamo tempo per testare". ne parlammo in tutta
franchezza e ci chiedemmo, ma è vero che le scadenze sono troppo
serrate oppure siamo noi che mettiamo le mani sul codice più e più
volte? guardando alle scadenze si vedeva che erano del tutto
ragionevoli, solo che molto del tempo veniva speso per risolvere in
urgenza bug di altre procedure. così cominciammo pian piano a mettere
su un impianto per gli unit test, prima sui nuovi sviluppi poi via via
su tutto il codice che veniva modificato, prima lanciati manualmente
poi in automatico. il risultato è stato incredibilmente sorprendente,
nel giro di pochi mesi le scadenze non era più un problema
rispettarle. e ti garantisco non è che stessimo applicando chissà
quale procedura test-driven spinta, certo poi siamo cresciuti e ci
siamo ulteriormente migliorati, ma inizialmente puntavamo
semplicemente a consegnare al cliente del codice che avesse *almeno*
girato una volta.

 girato una volta.
visto quello che c'e' in giro, e piu' che abbastanza: e' molto !