Articolo sugli "informatici" da La Stampa

[sirbone72]

Originariamente inviato da Nous

La premessa è vera, la conseguenza no.
Se vado in ritardo di un giorno nella consegna di software elegante, performante e testato il ritardo è di un giorno.
Se consegno nella scadenza una ciofeca, perderò mesi a debuggare, corregge, mettere pezze ottenendo un totale del tempo di sviluppo ben maggiore di quello preventivato e un sistema totalmente instabile in cui ogni modifica richiede un tempo abnorme per essere implementata a causa delle regressioni che sicuramente introduce sul sistema (che è tenuto insieme con lo sputo).

Se voi prendeste consapevolezza di questa cosa, chi sviluppa avrebbe una vita migliore

Il sospetto è che chi sviluppa, ci metta del suo . . . ogni modifica sono migliaian di euro
Comunque, lasciando d aparte gli scherzi, ci sono situazioni in cui non si può tardare. E? il caso di adeguamenti normativi, fermate impianti etc. In quei casi, meglio preventivare ritardi nelle modifiche in futuro, che partire in ritardo.

[Nous]

Originariamente inviato da sirbone72

Il sospetto è che chi sviluppa, ci metta del suo . . . ogni modifica sono migliaian di euro
Comunque, lasciando d aparte gli scherzi, ci sono situazioni in cui non si può tardare. E? il caso di adeguamenti normativi, fermate impianti etc. In quei casi, meglio preventivare ritardi nelle modifiche in futuro, che partire in ritardo.

Ti confermo che molte società in cui ho lavorato mi hanno sempre detto di consegnare il prima possibile, che eventuali bug non rilevati poi sarebbero stati fatturati a parte (cosa che a me ripugna e non ho mai fatto). Però il punto non è il preventivare i ritardi futuri, il punto è che se hai un'architettura schifosa o non hai un progetto ogni modifica al software diventa un campo minato su cui camminare.

[sirbone72]

Beh, ovvio che non si può consegnare un prodotto pessimo, altrimenti rischi ceh venga rifiutato perché non conforme alle specifiche o non funzionante. D'altro canto, anche per il software esiste la garanzia. . .
Rammento però che quando facevo il consulente (una vita fa), dovevo fare i salti mortali per rispettare le date di consegna. Sai quante "cablature" dentro il codice gridano ancora vendetta

[Nous]

Originariamente inviato da sirbone72

Sai quante "cablature" dentro il codice gridano ancora vendetta

Per questo gli informatici sono sottopagati..perchè lavorano poco professionalmente....se un dentista lavorasse così lo fucilerebbero tutti.

[sirbone72]

E' il gatto che si morde la coda. Stipendi bassi --> persone con poca esperienza --> lavoro di cattiva qualità --> pessima fama dei programmatori --> stipendi bassi.

[evelon]

Originariamente inviato da Nous

La premessa è vera, la conseguenza no.
Se vado in ritardo di un giorno nella consegna di software elegante, performante e testato il ritardo è di un giorno.
Se consegno nella scadenza una ciofeca, perderò mesi a debuggare, corregge, mettere pezze ottenendo un totale del tempo di sviluppo ben maggiore di quello preventivato e un sistema totalmente instabile in cui ogni modifica richiede un tempo abnorme per essere implementata a causa delle regressioni che sicuramente introduce sul sistema (che è tenuto insieme con lo sputo).

Se voi prendeste consapevolezza di questa cosa, chi sviluppa avrebbe una vita migliore

Non è così

Non dico che sia giusto o auspicabile ma nel mondo reale non è così.

Quello che consegni deve fare ciò per cui è stato progettato, anche se il codice è una ciofega, purchè funzioni.
Il debug e la stabilizzazione del prodotto sono già compresi nel contratto quindi l'azienda non perde di suo (sono costi preventivati che il cliente paga) purchè si rientri nei tempi.

Ed i tempi di debug e stabilizzazione sono definiti contrattualmente ma ci sono e sono stimati in modo statistico (a volte a "spanne") per ogni applicazione (chi lo fà ha esperienza e valuta in base alla complessità ed al tempo medio per applicazioni simili).

E' vero che le aziende tendono a mettere sotto pressione i programmatori dandogli tempi di stabilizzazione ridotti all'osso in modo da poter presentare preventivi più bassi ai clienti potenziali
Ma questi diventano problemi dei programmatori

Peraltro già il tipo di approccio dimostra che nè alle aziende, nè ai clienti interessa troppo la "pulizia" del codice

Infine una nota: la cosa varia da contratto a contratto ma generalmente ritardare di un giorno la consegna e la messa in esercizio è molto più oneroso (penali più alte) di prolungare di un giorno la stabilizzazione del codice che non è efficentissimo
Ed il cliente quando vede che davanti ad un bug imprevisto il funzionario commerciale propone "lasceremo il programmatore un giorno in più a sistemarlo" di solito lo interpreta come "serietà della ditta"

[yorkeiser]

Originariamente inviato da evelon

Non è così

Non dico che sia giusto o auspicabile ma nel mondo reale non è così.

Quello che consegni deve fare ciò per cui è stato progettato, anche se il codice è una ciofega, purchè funzioni.
Il debug e la stabilizzazione del prodotto sono già compresi nel contratto quindi l'azienda non perde di suo (sono costi preventivati che il cliente paga) purchè si rientri nei tempi.

Ed i tempi di debug e stabilizzazione sono definiti contrattualmente ma ci sono e sono stimati in modo statistico (a volte a "spanne") per ogni applicazione (chi lo fà ha esperienza e valuta in base alla complessità ed al tempo medio per applicazioni simili).

E' vero che le aziende tendono a mettere sotto pressione i programmatori dandogli tempi di stabilizzazione ridotti all'osso in modo da poter presentare preventivi più bassi ai clienti potenziali
Ma questi diventano problemi dei programmatori

Peraltro già il tipo di approccio dimostra che nè alle aziende, nè ai clienti interessa troppo la "pulizia" del codice

Infine una nota: la cosa varia da contratto a contratto ma generalmente ritardare di un giorno la consegna e la messa in esercizio è molto più oneroso (penali più alte) di prolungare di un giorno la stabilizzazione del codice che non è efficentissimo
Ed il cliente quando vede che davanti ad un bug imprevisto il funzionario commerciale propone "lasceremo il programmatore un giorno in più a sistemarlo" di solito lo interpreta come "serietà della ditta"

Ho iniziato (come tutti nel settore) programmando e adesso faccio progettazione sw/hw, affiancando talvolta i programmatori per le parti più delicate/complesse; ho più di 10 anni di esperienza nel settore e sinceramente la realtà da te delineata non l'ho mai vista... Che dirti, evidentemente i tuoi clienti si accontentano di robetta da 4 soldi che probabilmente pagano di meno, del resto ognuno ha un suo budget ed un suo target. La chiudo qui perchè è evidente che abbiamo modi di concepire il nostro lavoro troppo diversi; posso solo assicurarti che se dovessi acquistare del software funzionante e manutenibile (e a proposito, mi riferivo a quest'ultimo aspetto per la OOP, non certo alla facilità o meno dei linguaggi) non mi rivolgerei di certo a te
Spero che al di là di tutto questa polemica sia stata costruttiva. Passo e chiudo

[evelon]

Originariamente inviato da yorkeiser

Ho iniziato (come tutti nel settore) programmando e adesso faccio progettazione sw/hw, affiancando talvolta i programmatori per le parti più delicate/complesse; ho più di 10 anni di esperienza nel settore e sinceramente la realtà da te delineata non l'ho mai vista... Che dirti, evidentemente i tuoi clienti si accontentano di robetta da 4 soldi che probabilmente pagano di meno, del resto ognuno ha un suo budget ed un suo target. La chiudo qui perchè è evidente che abbiamo modi di concepire il nostro lavoro troppo diversi; posso solo assicurarti che se dovessi acquistare del software funzionante e manutenibile (e a proposito, mi riferivo a quest'ultimo aspetto per la OOP, non certo alla facilità o meno dei linguaggi) non mi rivolgerei di certo a te
Spero che al di là di tutto questa polemica sia stata costruttiva. Passo e chiudo

No problem per me, figurati

Il punto è che se mi definisci l'informatica gestionale come "complessa" e non "complicata" (concetti assai diversi ) allora i problemi complessi non li hai mai affrontati

Non si capisce cosa intendi per sw "funzionante" visto che il sw consegnato è sempre funzionante (altrimenti non passa nemmeno il collaudo....perchè i vostri clienti fanno il collaudo vero ? )

Per il resto immagino che la robetta da 4 soldi (? ma se non sai che faccio ) è cosa comune al settore proprio in virtù del fatto che la "gestionale" può essere complicata ma mai complessa (aka: strutture logiche che necessitano R&D a livelli sperimentali)

Anche perchè se la gestionale è complessa allora l'informatica scientifica cos'è ?

[durbans]

Originariamente inviato da Nous

Per questo gli informatici sono sottopagati..perchè lavorano poco professionalmente....se un dentista lavorasse così lo fucilerebbero tutti.

Non sono d'accordo.
Al dentista viene chiesto di fare un'otturazione fatta bene non di fare un'otturazione entro 15 minuti. Se ci mette mezzora non gliene frega niente a nessuno.

Al programmatore viene chiesta, spesso, come prima cosa, di rispettare la data di consegna.

[Chevelle]

Spesso e volentieri il commerciale va dal cliente senza capire nulla degli aspetti tecnici accollando, il programmatore, di responsabilità che non gli devono competere. Quando il progetto viene concretizzato, lo sviluppatore riceverà una gratificazione verbale mentre il commerciale riceverà un bel premio in denaro.
In caso contrario, il programmatore molto probabilmente viene licenziato ed il commerciale sicuramente conserva la sua sedia. Questo accade perchè manca la figura dal capo progetto. Il programmatore dovrebbe scrivere le specifiche fornite dal suo diretto superiore (analista e "architetto") e solo lui dovrebbe rispondere di eventuali errori o ritardi dei tempi di consegna.
Nell' azienda dove lavoro ciò non succede.