Indice del forum Olimpo Informatico
I Forum di Zeus News
Leggi la newsletter gratuita - Attiva il Menu compatto
 
 FAQFAQ   CercaCerca   Lista utentiLista utenti   GruppiGruppi   RegistratiRegistrati 
 ProfiloProfilo   Messaggi privatiMessaggi privati   Log inLog in 

    Newsletter RSS Facebook Twitter Contatti Ricerca
L'incubo di ogni programmatore
Nuovo argomento   Rispondi    Indice del forum -> Programmazione
Precedente :: Successivo  

Qual è la cosa peggiore per un programmatore? (possono rispondere anche i non programmatori!)
Bachi
1%
 1%  [ 1 ]
Modifica delle specifiche
15%
 15%  [ 11 ]
I clienti
27%
 27%  [ 19 ]
Debuggare
5%
 5%  [ 4 ]
Scrivere documentazione
7%
 7%  [ 5 ]
Riunioni
0%
 0%  [ 0 ]
Codice scritto da altri
33%
 33%  [ 23 ]
Testare
5%
 5%  [ 4 ]
Altro (specificare)
2%
 2%  [ 2 ]
Voti Totali : 69

Autore Messaggio
fdd
Dio maturo
Dio maturo


Registrato: 22/04/05 00:33
Messaggi: 1734
Residenza: Giusto dietro l'angolo

MessaggioInviato: 19 Ott 2006 01:20    Oggetto: L'incubo di ogni programmatore Rispondi citando

Leggi l'articolo su Zeus News

L'ultima modifica di fdd il 02 Nov 2006 00:38, modificato 1 volta
Top
Profilo Invia messaggio privato
Gateo
Dio maturo
Dio maturo


Registrato: 17/11/03 18:16
Messaggi: 12379

MessaggioInviato: 19 Ott 2006 09:08    Oggetto: Rispondi citando

Bello questo sondaggio!
Dico la mia, sempre se un database di Access me lo passate come programmazione.
Il cliente , in questo caso l'utilizzatore finale e' sempre stata la parte peggiore.
Mai dirgli "se c'e' qualche problema dimmi pure, che in un attimo te lo modifico": dopo infinite modifiche all'usabilita', ai report, al controllo errori, all'interfaccia grafica ho finalmente realizzato che semplicemente l'utente il database non lo voleva usare, per tirare avanti coi suoi copia/incolla tra un centinaio di documenti di word ed excel.
Capito questo e fatti sparire quei documenti, il database e' risultato perfetto. Evil or Very Mad
Top
Profilo Invia messaggio privato
horus
Macchinista
Macchinista


Registrato: 22/03/05 09:48
Messaggi: 2554
Residenza: Sirio e dintorni

MessaggioInviato: 19 Ott 2006 14:27    Oggetto: Rispondi citando

E' stata dura scegliere tra clienti e specifiche. Alla fine ho optato per le specifiche.

Immagina lo scenario: a seguito di ore e ore di analisi si è finalmente deciso un flusso, realizzi la struttura del db con tutte le tue belle chiavi, gli indici ecc; crei le maschere e il software che gestisce gli scambi di dati col db secondo query ed algoritmi molto complessi. Funziona tutto, sei felice. Poi qualcuno (capo/analista) ti dice: "A seguito di ulteriore riflessione si è deciso che il flusso dovrebbe essere quest'altro!". A questo punto ricominci da capo a modificare la struttura del db cercando di salvare qualcosa del lavoro già fatto e poi crei le maschere e il software che gestisce gli scambi di dati col db secondo query ed algoritmi molto complessi. Funziona tutto, sei felice. Poi qualcuno (capo/analista) ti dice........ [continua]
Ah, ovviamente la scadenza in cui consegnare il prodotto non cambia mai.
Top
Profilo Invia messaggio privato
fdd
Dio maturo
Dio maturo


Registrato: 22/04/05 00:33
Messaggi: 1734
Residenza: Giusto dietro l'angolo

MessaggioInviato: 23 Ott 2006 18:06    Oggetto: Rispondi citando

Personalmente non sono un programmatore, ma giusto ieri parlavo con un amico che fa invece questo di professione. Ebbene lui mi ha detto che per quanto a volte quasi si impazzisca alla ricerca dei bug, alla fin fine basta essere analitici e con un po' di logica si viene a capo di tutto. Ciò contro cui invece nulla si può è il fattore umano, e cioé i clienti (che è l'opzione che scelta) in cui faceva rientrare anche la loro volubilità nel modificare le specifiche del prodotto.
Top
Profilo Invia messaggio privato
kluster
Dio maturo
Dio maturo


Registrato: 15/04/06 12:14
Messaggi: 2898

MessaggioInviato: 23 Ott 2006 18:13    Oggetto: Rispondi citando

si, cambio specifiche. Mi ricordo un gestionale che aveva per una tabella fondamentale una relazione uno a molti, ed il giorno prima di andare in produzione venne fuori che era un molti a molti, multi tipologia. Che casino, poi cmq è andata.
Anche se cmq mettere le mani su un codice altrui (sopratuttutto non commentato) è un'altra bella dannazione.
Top
Profilo Invia messaggio privato
Smjert
Dio maturo
Dio maturo


Registrato: 01/04/06 17:19
Messaggi: 1619
Residenza: Perso nella rete

MessaggioInviato: 23 Ott 2006 19:12    Oggetto: Rispondi citando

Non mi posso considerare programmatore però ho risposto al sondaggio lo stesso mettendo "Codice scritto da altri".
Questo cosa l'ho riscontrata mentre mi divertivo a creare scripts (in c#) per l'emulatore RunUo, che appunto emula il famosissimo (nevvero?) gioco online Ultima Online.
Sopratutto il problema stava nel nome delle varibili e delle funzioni... che poteva cambiare il significato e l'apparente funzionamento dello script da così a così.
Top
Profilo Invia messaggio privato HomePage
madvero
Amministratore
Amministratore


Registrato: 05/07/05 20:42
Messaggi: 19480
Residenza: Ero il maestro Zen. Scrivevo piccole poesie Haiku. Le mandavo a tutti via e-mail.

MessaggioInviato: 23 Ott 2006 22:08    Oggetto: Rispondi citando

specifiche, sicuramente specifiche.
da cliente, quando chiamo gli sviluppatori e faccio presente che dovrebbero invertire un paio di cosucce, generalmente si danno malati, staccano il telefono e partono per le maldive.
Top
Profilo Invia messaggio privato Invia e-mail HomePage
Smjert
Dio maturo
Dio maturo


Registrato: 01/04/06 17:19
Messaggi: 1619
Residenza: Perso nella rete

MessaggioInviato: 23 Ott 2006 22:14    Oggetto: Rispondi citando

madvero ha scritto:
specifiche, sicuramente specifiche.
da cliente, quando chiamo gli sviluppatori e faccio presente che dovrebbero invertire un paio di cosucce, generalmente si danno malati, staccano il telefono e partono per le maldive.


ROTFL

Insomma... gente con voglia di fare!
Top
Profilo Invia messaggio privato HomePage
madvero
Amministratore
Amministratore


Registrato: 05/07/05 20:42
Messaggi: 19480
Residenza: Ero il maestro Zen. Scrivevo piccole poesie Haiku. Le mandavo a tutti via e-mail.

MessaggioInviato: 24 Ott 2006 00:54    Oggetto: Rispondi citando

ma no... è che gli sviluppatori si fanno un loro schema mentale in base all'ordine in cui, secondo loro, dovrebbero essere effettuate determinate operazioni. tale ordine avrebbe anche un suo rigore logico/informatico, se non cozzasse paurosamente con l'ordine consequenziale e logico che seguiamo noi utilizzatori del programma.
in pratica, loro impostano
a > b > c > d
ma noi dobbiamo fare
d > c > confermi?y/n > sei sicuro?y/n > sicuro sicuro?y/n > d > b > confermi?y/n > sei sicuro?y/n > sicuro sicuro?y/n > d > a > confermi?y/n > sei sicuro?y/n > sicuro sicuro?y/n > d
vedi, è a questo punto che scattano i vaff...
Top
Profilo Invia messaggio privato Invia e-mail HomePage
GrayWolf
Dio maturo
Dio maturo


Registrato: 03/07/05 16:24
Messaggi: 2325
Residenza: ... come frontiera i confini del mondo...

MessaggioInviato: 24 Ott 2006 02:22    Oggetto: Rispondi citando

Da sviluppatore trovo difficile rispondere con una sola opzione

Il lavoro di sviluppo di un'applicazione è sempre complesso per le variabili che entrano in gioco:

- un linguaggio comune fra richiedenti [clienti] e fornitori [analisti/sviluppatori].

- Esposizione/Comprensione delle esigenze: molte volte il cliente non è in grado di spiegare esattamente ciò che vuole e altrettanto lo sviluppatore non è in grado di capire ciò che gli viene richiesto. Read

- La mancanza di conoscenza [o della voglia di conoscere] da parte del cliente delle regole ferree che si devono seguire per garantire l'integrità dei dati, un esempio classico è quello del vincolo referenziale fra tabelle di database; se cerchi di spiegarlo, anche in termini semplici [sbagliato, non si dovrebbe mai fare] ti senti rispondere: "Lei mi fa venire il mal di testa".

- la disabitudine dei clienti a fare attenzione ai passaggi intermedi per la costruzione di un'informazione, normalmente considerano l'inizio e la fine, "quello che ci sta in mezzo e come viene fatto" non sono affari loro, normalmente la richiesta è: "schiaccio un bottone e lui [il calcolatore/programma] deve fare questo e questo e questo e..." Shocked



Una mia personale graduatoria degli incubi, con valore a decrescere è:

Clienti Evil or Very Mad

Specifiche [modifica delle] KO

Programmi scritti da altri, quando sono senza commenti o peggio sono degli "spaghetti code" e commentati in modo astruso [vedi linguaggio molto personalizzato]TapTap

Documentazione: in corso d'opera "quando si è freschi" è abbastanza agevole [fatta salva la sua comprensione] il suo aggiornamento invece è estramente complicato e molte volte non segue le modifiche apportate. Phew
Top
Profilo Invia messaggio privato
ioSOLOio
Amministratore
Amministratore


Registrato: 12/09/03 18:01
Messaggi: 16342
Residenza: in un sacco di...acqua

MessaggioInviato: 28 Ott 2006 14:10    Oggetto: dal lato del cliente la prospettiva è diversa Rispondi citando

io sono proprio impegnato in questo periodo con un grosso programma da modificare/perfezionare..

io sono dalla parte del cliente...di fronte ho la società che ha creato la ciofeca..ops..il programma...e che deve modificare alcune situazioni e "aggiustare" alcuni palesi malfunzionamenti.

Sicuramente credo che di solito cliente + specifiche mal poste siano i problemi più dificili da gestire per i programmatori.
In questo caso invece...sono io che ho difficoltà a gestire i programmatori se non a calcioni nel di dietro..e vi assicuro che sono un precisino come non mai nei dettagli delle modifiche o degli errori segnalati.

Furibondo
Top
Profilo Invia messaggio privato
dasio78
Dio maturo
Dio maturo


Registrato: 22/06/06 22:05
Messaggi: 6282

MessaggioInviato: 30 Ott 2006 01:05    Oggetto: clienti sempre scontenti di qualcosa Rispondi citando

non sono un programmatore, ma per esperienze analoghe non posso che optare per i clienti, o scontenti del lavoro o del prezzo, ma sempre scontenti!
Top
Profilo Invia messaggio privato
Epimenide
Comune mortale
Comune mortale


Registrato: 02/11/06 08:56
Messaggi: 3
Residenza: Bucks., UK

MessaggioInviato: 02 Nov 2006 09:33    Oggetto: Possono essere un problema oppure anche no... Rispondi citando

Come programmatore, e da un bel po' di tempo, vorrei anche io dire la mia sui vari punti:

  1. Bachi: non esiste il codice (o il programmatore) perfetto, i bachi sono cosa di tutti i giorni. È un po' come chiedere al meccanico se il problema del suo lavoro sono le mani sporche....
  2. Modifica delle specifiche: qui entra in gioco la metodologia di lavoro. Usando (dopo averla capita) la metodologia XP (eXtreme Programming, mi raccomando!), le specifiche possono cambiare, e normalmente lo fanno, ma solo ad intervalli predeterminati (brevi!), e dopo l'accettazione dell'esistente. Per cui, smettono di essere un problema e diventano parte del processo di sviluppo.
  3. I clienti: qui l'errore è di fondo. So che non è sempre possibile in realtà piccole, ma il programmatore dovrebbe incontrare il cliente il meno possibile, proprio per non farsi distrarre da problemi posti male o inesistenti. In questo senso un buon project manager o analista (ovvero, uno che sappia quello che fa e non scarichi le colpe sugli altri) è impagabile.
  4. Debuggare: vedi punto 1. Semmai il problema sono gli ambienti/linguaggi in cui è un incubo il processo di debug stesso...
  5. Scrivere documentazione: era il mio terzo favorito per il voto. Bisogna però dire che, se viene fatto bene, sconfigge facilmente il mio primo (codice di altri). Quindi, una noia, ma i risultati poi si vedono.
  6. Riunioni: il mio secondo favorito: non tanto per le riunioni in sé, ma per quelle senza capo né coda... So che può sembrare poco serio, ma mantenerle in un tono leggero e scherzoso (e, perché no, fatte in posti tipo bar o pizzeria) dà molti più risultati! Certo, niente clienti... ma per quello, vedi il punto 3!
  7. Codice scritto da altri: la mia bestia nera! Anche qui, un approccio XP (tenere chiaro il codice, evitando scorciatoie che fanno tanto hack/guarda-che-bravo-che-sono e commentarlo nei punti cruciali) ha il suo valore!
  8. Testare: un male necessario. Devo tirare fuori XP (con i suoi unit test) un'altra volta? Wink
Top
Profilo Invia messaggio privato HomePage
{utente anonimo}
Ospite





MessaggioInviato: 02 Nov 2006 09:44    Oggetto: Genericità Rispondi citando

E' questo l'unico vero problema: se lo sviluppatore (programmatore è parola d'altri tempi) non è in grado di generalizzare e astrarre, un semplice cambio di specifica rende il tutto da buttare.
Top
marcOpera
Eroe
Eroe


Registrato: 19/04/06 00:12
Messaggi: 51
Residenza: Torino

MessaggioInviato: 02 Nov 2006 12:57    Oggetto: Rispondi citando

E' da 23 anni che scrivo programmi...

Per me la cosa più complessa è riuscire a gestire correttamente la modifica delle specifiche, con il minor spreco possibile di tempo, e con il giusto riconoscimento economico.

Chiaramente la possibilità che vengano richieste variazioni delle specifiche è intimamente connessa con la tipologia di Cliente con il quale si ha a che fare.

C'è il Cliente pasticcione che gestisce le sue procedure (anche manuali) senza seguire alcuna logica, tendendo sempre ad improvvisare: è il caso peggiore, perché non avendo già lui stesso una visuale organica, difficilmente potrà illustrare ad altri quali strade seguire per risolvere i suoi problemi...

C'è il Cliente che invece segue rigidamente uno schema che si è costruito in anni di lavoro, e che non vuole/riesce a cambiare, neanche di fronte all'evidenza che le stesse cose che è abituato a fare in un certo modo possono essere fatte in tutt'altra maniera, semplificando il suo (ed il mio...) lavoro.

E per fortuna c'è anche il Cliente che ha le idee chiare, ragiona in maniera schematica, ed è persino in grado di fornire una rappresentazione grafica del flusso delle operazioni da compiere.
E' addirittura disposto a mettere in discussione le sue modalità operative, se gli si presentano delle idee che lo convincono.
E' un vero piacere lavorare con elementi simili...

Altri Clienti che danno soddisfazione sono quelli che addirittura conoscono i rudimenti della programmazione, magari hanno persino tentato di risolversi qualche piccolo problema, ed hanno così potuto toccare con mano i piaceri dello sviluppo. Sono quelli che oppongono minore resistenza, perché si sono scontrati con i casini annessi, ed accettano qualunque soluzione senza fiatare. Sono anche gli unici in grado di capire che una modifica che sembra banale potrebbe anche portare via due giorni di tempo...

Per cercare di non farsi sviare troppo da informazioni lacunose, false e tendenziose, quando effettuo le mia analisi, cerco di passare quanto più tempo possibile presso il Cliente, guardandolo lavorare e cercando di vedere personalmente quali siano i passaggi da seguire per gestire informaticamente il flusso dei dati per arrivare agli obiettivi indicati.

Per esempio, mi è capitato di dover gestire un magazzino di semilavorati per pasticceria, con l'implementazione di un sistema di codifica tramite barcode e terminali portatili. Durante la giornata passata con loro ho scoperto che trattavano anche i surgelati... valle ad etichettare, delle scatole che quando vengono scaricate dal camion per essere messe in cella, si ricoprono di goccioline di condensa! E me ne sono accorto solo perché ero presente!

Preferisco l'analisi fatta in reparto, piuttosto che nella sala riunioni.

Ho letto in un post precedente l'elogio della figura dell'analista... secondo me è invece da cassare in toto, perché normalmente non conosce né il tipo di lavoro che svolge il Cliente, né gli strumenti a disposizione del programmatore.

Se ci vado io dal Cliente, certamente devo prima capire di cosa si occupa il Cliente e come, ma almeno per quello che riguarda il mio di lavoro, ne ho una visione che l'analista se la scorda.

Mentre il Cliente mi parla, io sto già immaginando i pezzi di codice che potrò riutilizzare, mi viene in mente che ho già risolto un problema simile per il Cliente xy in una certa maniera, ecc.

E, sempre secondo me, maggiore è il numero di persone che fungono da intermediari tra il Cliente e lo Sviluppatore, maggiore è la possibilità di incomprensioni e fraintendimenti. E se ho un dubbio, durante la stesura del programma, che faccio, spiego all'analista qual è il mio problema, gli dico di ricontattare il Cliente, di farsi spiegare meglio un passaggio e poi di raccontarmi che cosa ha capito? Mi sembra macchinoso, e foriero di casini ulteriori...

Il vero problema è il preventivo...

Quando ne devo presentare uno ad un Cliente, specifico sempre che se, a seguito della stesura iniziale del programma e dell'installazione presso la sua sede, dovessero emergere delle modifiche e/o migliorie da apportare, si dovrà ridiscutere la parte economica.

Ho preso l'abitudine di fornire dei preventivi estremamente dettagliati, comprensivi di videate di acquisizione dati e prototipi di stampa, e pretendo che vengano attentamente vagliati ed approvati prima di dare il via ai lavori.

La cosa più difficile è fare percepire ed accettare al Cliente che modifiche richieste in corso d'opera o successive alla consegna saranno sicuramente eseguite, ma riconosciute come extra.

Ciaociao.

Marco
Top
Profilo Invia messaggio privato
Epimenide
Comune mortale
Comune mortale


Registrato: 02/11/06 08:56
Messaggi: 3
Residenza: Bucks., UK

MessaggioInviato: 02 Nov 2006 15:29    Oggetto: Rispondi citando

Marco,
quello che dici è tutto bello e giusto... finché consideri lo sviluppo software come artigianato, eseguito da una o al massimo due persone!

Quello che segue non è da prendere come una critica, semmai di avviare una discussione (da proseguire anche offline, i miei dati qui sono pubblici).

Anche io, come te, ho ben più di 20 anni di esperienza di programmazione, ed ho lavorato sia alla tua maniera che con aziende di dimensione nazionale e globale (prova ne è che da più di 10 anni non lavoro in Italia). Con queste ultime, e con progetti di un certo respiro, il tuo approccio semplicemente non funziona.

L'analista non sarà una figura necessaria nel tuo ambito, ed anche io ho lavorato con analisti che sarebbero stati più utili al progetto come fattorini, visto che il loro lavoro era più d'intralcio che altro, ma ti assicuro che, quando il project manager fa bene il suo lavoro, lo sviluppo ne ha tutto da guadagnare!

Certo, puoi far presente al cliente tutto quello che vuoi, ma considerare le modifiche alle specifiche una parte integrante del progetto, ed operare di conseguenza, evita sorprese a te e al cliente.

In questo, l'approccio XP (che ti invito a valutare) è prezioso, se riesci ad illustrarlo e farlo accettare al cliente: il progetto viene mandato avanti in una serie di task, che aggiungono progressivamente nuove funzioni, via via accettate (e pagate). In questo modo non si arriva mai alla fine con un prodotto che il cliente, per motivi suoi, può rifiutare o insistere col modificare: se qualcosa non va bene, viene identificata molto prima, e la perdita di tempo per lo sviluppatore è minimizzata.

Non pretendo di aver sviscerato del tutto l'argomento, su XP esistono fior di libri, spero solo di aver suscitato la curiosità per saperne di più!
Top
Profilo Invia messaggio privato HomePage
marcOpera
Eroe
Eroe


Registrato: 19/04/06 00:12
Messaggi: 51
Residenza: Torino

MessaggioInviato: 02 Nov 2006 17:24    Oggetto: Rispondi citando

Epimenide,

mi dimentico sempre che io sono abituato a pensare in piccolo. D'altronde è vero, siamo solo in due (e ci resteremo a lungo, mi sa...), ma la mia esperienza in fatto di progetti più ampi sono riuscito in qualche modo a farmela, lavorando come consulente per aziende decisamente più grandi della mia.

Avevo già letto qualcosa circa l'eXtreme Programming, ma adesso che me lo hai ricordato tu sono andato a riguardarmi il testo che mi ero messo da parte.

E mi sono ricordato che già allora avevo detto al mio socio “noi non lo sapevamo, ma è dal 1989 che lavoriamo secondo i dettami dell'eXtreme Programming...”

E' da sempre che chi bazzica nell'informatica è al corrente del fatto che sviluppare per dei mesi, chiusi nella propria torre d'avorio, e presentare il frutto del proprio lavoro aspettandosi di aver compreso appieno le esigenze del Cliente, spesso espresse in maniera imprecisa, e di non dover più mettere mano al codice, sia un'utopia irrealizzabile.

Però è anche da sempre che il Cliente si aspetta un costo certo e che non lieviti a livelli imprevedibili.

Ottenuta però la fiducia del Cliente stesso, è molto più facile fargli “digerire” il fatto che lo sviluppo di un programma non può essere ridotto al solo “ti do questo e quello, a tot euro ed in tot tempo”, ma è un processo decisamente più articolato. Non si tratta di vendere mattoni!

Avevo trovato (proprio perché lo pratico da sempre) il concetto del lavoro “in binomio” veramente interessante, d'altronde è operando in questa maniera che io ed il mio socio abbiamo potuto sviluppare un discreto quantitativo di applicativi in cui tutti sanno tutto di tutto, limitando al massimo la scrittura di documentazione ed essendo diventati in pratica perfettamente intercambiabili.

Noi siamo arrivati a scrivere codice in simbiosi perfetta, ovvero abbiamo addirittura lo stesso stile, lo stesso modo di indentare il codice, di aggiungere linee vuote, di scrivere i commenti... a tal punto che anche se siamo intervenuti in tempi diversi sullo stesso sorgente, è praticamente impossibile distinguere i punti che ho modificato io o che ha modificato lui.

Durante il periodo in cui ho avuto modo di fare il consulente, ho lavorato alla modifica di un software per il controllo di un'apparecchiatura per analisi ematiche, commissionato da una multinazionale americana, assieme ad un dipendente della ditta che mi aveva “arruolato”.

La prima cosa che mi aveva colpito era stata la quantità abnorme, secondo i miei standard, di cartaccia che viaggiava insieme al codice. Sul codice stesso, in C++, avevano lavorato più di una decina di persone, accompagnate da una pletora di analisti, project manager e “responsabili” vari.

Il codice non era scritto in maniera uniforme, lo stesso problema era stato affrontato in almeno tre modi differenti in tre sorgenti differenti, insomma, sembrava che la parola “coordinazione” fosse completamente sconosciuta.

Come ciliegina sulla torta, la documentazione cartacea non era ovviamente allineata all'ultima release, e delle persone che avevano lavorato al progetto più nessuna era reperibile. Una vera goduria!

Terminata la prima fase di modifiche piuttosto pesanti, rilasciavamo una nuova versione ogni due settimane circa, ed in tali occasioni ricevevamo nuovi input dal committente.

Beh, dopo un anno e mezzo di lavoro in due, operando spesso alla medesima postazione, abbiamo ricevuto i complimenti dei responsabili americani del progetto, che si erano stupiti della mole di lavoro che eravamo riusciti a svolgere, pur essendo due gatti rispetto ai componenti del gruppo di sviluppo originale. E tutti e due sapevamo quali modifiche erano state fatte ed in quali punti!

Miracoli dell'XP, anche se allora non ero consapevole di utilizzarlo!

Ciaociao.

Marco
Top
Profilo Invia messaggio privato
Epimenide
Comune mortale
Comune mortale


Registrato: 02/11/06 08:56
Messaggi: 3
Residenza: Bucks., UK

MessaggioInviato: 03 Nov 2006 05:43    Oggetto: Miracoli dell'XP... Rispondi citando

Marco,
fa piacere sentire che hai avuto successo, un successo che, ti faccio notare, in qualche punto non combacia proprio con il primo messaggio! Wink

Certo, in molte, troppe aziende l'XP non è ancora arrivato, e l'equazione grande azienda = grande software è di là da essere vera, quello che mi premeva far notare è che alternative alla concezione tradizionale di sviluppo software possono funzionare a qualsiasi livello.
Top
Profilo Invia messaggio privato HomePage
{D}
Ospite





MessaggioInviato: 03 Nov 2006 09:35    Oggetto: Sottovalutare Rispondi citando

Una delle "cose peggiori" per il programmatore (o sviluppatore, o affini) è accettare una commissione e **sottovalutare** la complessità del progetto che si deve sviluppare.
In breve: farsi pagare per due mesi di lavoro e impiegarne sei! (...al terzo mese il cliente già comincia a incazzarsi, etc etc etc etc)
Un incubo.
Top
marcOpera
Eroe
Eroe


Registrato: 19/04/06 00:12
Messaggi: 51
Residenza: Torino

MessaggioInviato: 03 Nov 2006 09:54    Oggetto: Rispondi

Epimenide,
dire che ho avuto successo è una parola grossa... Wink

Diciamo che almeno qualche lavoro è stato portato a termine senza la presenza di fastidiosi effetti collaterali... Smile

Io non saprei dire se l'approccio dell'XP sia più difficile da inculcare ai committenti od alle aziende che sviluppano software.

Certo è che in molte realtà, il vedere due persone che lavorano allo stesso terminale viene percepito più come uno spreco di risorse che non come un vantaggio.

Io invece lo trovo estremamente stimolante, e molto più produttivo che stare per ore a digitare in perfetta solitudine davanti al proprio monitor.

In più lo scambio continuo di esperienze è formidabile per la propria (ed altrui) crescita, dato che in questo mestiere non si smette mai di imparare, e c'è sempre qualcuno che, per quanto tu sia capace, conosce qualche trucchetto in più...

Ciaociao.

Marco
Top
Profilo Invia messaggio privato
Mostra prima i messaggi di:   
Nuovo argomento   Rispondi    Indice del forum -> Programmazione Tutti i fusi orari sono GMT + 1 ora
Vai a 1, 2, 3  Successivo
Pagina 1 di 3

 
Vai a:  
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi