[Tez]

Ursprungligen postat av autosvar

Har du testat och godkänt den levererade koden?

Njaeeeetja... Vi har inte så stor budget för utveckling, så det handlar om att göra mindre tillägg och förbättringar hela tiden allteftersom vi får råd, inte att bygga ett helt nytt system. Vi har en helt egenutvecklad webshop nämligen, och jag har maaaassor av önskemål om förändringar. Det är alltså ett ganska "informellt" och kontinuerligt samarbete vi har, inte offert - avtal - leverans - godkännande - klart - hejdå.

Ibland meckar jag lite själv, bland annat fick jag hybris igårkväll och trodde att jag kunde. Men jag ska nog hålla mig till text och bilder för imorse var inkorgen full med mail från kunder som inte kunde beställa... :blink: Så det var bara att ladda upp de gamla filerna igen.

Har dock inget med den aktuella buggen att göra. I det här fallet handlade det om en funktion som tillsynes fungerade utmärkt, men defacto fungerar ibland och ibland inte.

[Tez]

Originally posted by Weaver@Jun 9 2008, 17:46
Vid sådana här fall kan det vara bra att ha en "extra" programmerare som bollplank åt orginal-programmeraren. Köp en timmes konsulttid av din "extra" programmerare och få ett utlåtande av honom.

Smart. Men blir det inte svårt för den "extra" programmeraren att lyckas sätta sig in i allt på så kort tid? Och komma ihåg tills nästa gång det är aktuellt?

[Drew]

Om koden är någorlunda vettigt skriven och kommenterad tar det inte lång tid att sätta sig in i dom delar som behövs. För att felsöka en del av koden behöver man oftast inte sätta sig in i hur allt är uppbyggt.

Det viktiga är en så utförlig felbeskrivning som möjligt. Kan man återskapa felet går det ofta ganska fort att hitta felkällan även om man aldrig sett koden innan. Om det är väldigt rörig och oorganiserad kod tar det självklart längre tid.

[Tez]

Originally posted by Drew@Jun 9 2008, 22:14
Om koden är någorlunda vettigt skriven och kommenterad tar det inte lång tid att sätta sig in i dom delar som behövs. För att felsöka en del av koden behöver man oftast inte sätta sig in i hur allt är uppbyggt.

Det viktiga är en så utförlig felbeskrivning som möjligt. Kan man återskapa felet går det ofta ganska fort att hitta felkällan även om man aldrig sett koden innan. Om det är väldigt rörig och oorganiserad kod tar det självklart längre tid.

Tyvärr har vi aldrig lyckats återskapa felet. Det händer ibland bara, och vi har inte lyckats hitta variabeln som orsakar det.

[wooper]

Det är en lite klurig situation du sitter i.
Nu vet jag inte vad din programmerare har sagt till dig om hur buggen skall fixas men jag vet med erfarenhet att buggar som är kluriga och tillsynes helt oförklarliga inte direkt hamnar långt upp på prioritetslistan - och som du själv säger, buggen uppstår bara ibland / sällan.

MEN: I mitt tycke skall programmeraren i alla fall kolla på buggen, beräkna tid att fixa den, och sedan prata med dig om ett konstnaddsförslag.

OM: Det handlar om PHP och MySQL kan jag bidra med att titta på / analysera buggen utan kostnad (utan restriktioner för när det ska vara gjort/klart).

EDIT: Stavning.

[MrHandley]

Du har väl köpt funktioner som skall utvecklas?
Om funktionen inte fungerar som den skall så skall det åtgärdas.

Egentligen börjar du i fel ända, dvs att du borde ha specat när du köpte utveckling hur eventuella fel skulle åtgärdas.

Men det är för sent nu. Jag tycker inte att du skall betala extra för felsökningstid alls. Det är inte ditt problem.

[Bjarne]

Det är svårt med buggar, sitter själv och felsöker och rättar sådana då och då. Generellt så tycker jag man inte alls kan ta betalt för felsökningen, om det inte i slutänden visar sig vara kunden som är orsaken, eller en tredjepartare. Det kan t. ex vara att kunden ändrat arbetsrutiner eller avviker från det tänkta flödet, ändringar i något tredjepartsprogram eller något sådant.

Är det rena felaktigheter i min kod så får jag se till att rätta detta, utan att det ska behöva drabba kunden.

Extra svårt är det givetvis med luddiga buggar, som kanske inte ens kan återskapas. Min grundregel är att jag ger det en halvtimme till att börja med för att återskapa felet, men om inte det låter sig göras får jag höra av mig till kunden och diskutera hur vi går vidare.

[Magnus_A]

Det har jag råkat ut för som beställare och efter att jag gjorde klart för honom att hans offert gällde en fungerande lösning så var det slut med att debitera buggfixtid.
Ändringar i efterhand är en annan sak, så det gäller att hålla käften som beställare. Annars kan det bli dyrt.

[goose]

Jag jobbar som utvecklare och jag tycker att man självklart till en viss mån (2-3timmar kanske) kan fixa buggar i efterhand. Men när kunden har testat och godkänt leverans så är systemet levererat i sitt befintliga skick. System och miljö ändras ju efterhand och de förutsättningar som gällde innan kanske inte gäller längre. Man kan ju inte sitta och ge gratis support för ett system hela livet heller. Även utvecklare behöver ha mat på bordet Du säger att du går in och grejar själv i koden, även fast du inte har de kunskaperna, det är inte ett beteende som får en att ha dig som drömkund precis

Den som är beställare har en väldigt stor roll i hur bra systemet blir. Skriver du ingen vidare kravspec eller testar av leveranser så blir det ofta inte så bra.

[Tez]

Nja, om jag grejar i koden själv så kör han alltid en jämförelse och kollar mina ändringar, så det är aldrig något problem. Det är bara pluttgrejer jag gör egentligen flyttar lite saker och så. Igår tog jag bort faxinfo ifrån kunduppgifterna. Vad ska vi med deras faxnummer till, det är bara onödigt. Så hade jag missat en detalj som gjorde att det sket sig med databasen.

Sedan är det förmodligen så att ni föreställer er att det är ett mycket större system än vad det är. Jag skulle kunna räkna upp precis alla filer som ingår, och säga vilken fil som innehöll vad. Därför är buggen ännu mer oförklarlig... Det är inte större än så. Det kommer inte bli någon konflikt angående detta, jag tyckte mest att det var en intressant diskussion.

För övrigt är jag en drömkund , eftersom jag förstår vad han pratar om och anpassar mina önskemål efter hur koden redan ser ut.