Bugs: meteen oplossen of eerst registreren?

[Croga]

Modbreak:

Dit topic is afgesplitst van Broncode Basisregistratie Personen openbaar.

Keiichi schreef op donderdag 30 november 2017 @ 21:01:
'Known Issues.xlsx' Daar gebruik je toch jira/redmine/whateverissuetrackingsysteem voor?

Nee. Dubbel Nee! TRIPPEL NEE!

Wat doe je met known issues? Ga je die verstoppen in een excel sheet? Ga je die wegvrotten in Jira? Nee, DIE LOS JE OP!

Iedere minuut die een known issue langer bestaat wordt het lastiger hem op te lossen. Dus als je een known issue tegen komt, dan laat je alles uit je handen vallen en los je de issue op!

Bron: Taiichi Ohno, "The Toyota Way"
(Oh ja, en iedereen die zich ooit serieus bezig gehouden heeft met het proces van software ontwikkeling)

[ Voor 7% gewijzigd door NMe op 02-12-2017 12:02 ]

[NMe]

Croga schreef op vrijdag 1 december 2017 @ 13:02:
Iedere minuut die een known issue langer bestaat wordt het lastiger hem op te lossen. Dus als je een known issue tegen komt, dan laat je alles uit je handen vallen en los je de issue op!

Ben je nou sarcastisch of meen je dit serieus? Er zijn talloze redenen waarom je issues niet acuut oppakt:

1. De issue is niet belangrijk genoeg.
2. De issue is wel belangrijk maar andere dingen zijn nóg belangrijker.
3. De issue kost meer om te fixen dan het zou kosten om ermee te leren leven.
4. De issue kán gewoon niet opgelost worden.
5. De issue komt voort uit veranderde specs en de klant wil niet betalen voor het oplossen.

Een paar van de grootste projecten op het internet hebben duizenden known issues die soms zelfs jarenlang open blijven staan.

[downtime]

Croga schreef op vrijdag 1 december 2017 @ 13:02:
[...]

Nee. Dubbel Nee! TRIPPEL NEE!

Wat doe je met known issues? Ga je die verstoppen in een excel sheet? Ga je die wegvrotten in Jira? Nee, DIE LOS JE OP!

Iedere minuut die een known issue langer bestaat wordt het lastiger hem op te lossen. Dus als je een known issue tegen komt, dan laat je alles uit je handen vallen en los je de issue op!

Bron: Taiichi Ohno, "The Toyota Way"
(Oh ja, en iedereen die zich ooit serieus bezig gehouden heeft met het proces van software ontwikkeling)

Die registreer je voordat je ze oplost. Omdat ze toch ergens geregistreerd moeten worden. Gebruik je geen Excel of Jira dan gebruik je wel email of gewoon een kladblok. Maar dan weet niemand behalve die ene developer waar ze aan werken en of ze wel aan de werkelijk belangrijke issues werken.

En een softwareproject is geen fabriek waar 100.000 identieke units per jaar van de lopende band rollen. Daar wil je known issues inderdaad meteen oplossen omdat je ze anders bij de dealer of via een terugroepactie moet oplossen.

[MuddyMagical]

Croga schreef op vrijdag 1 december 2017 @ 13:02:
[...]

Nee. Dubbel Nee! TRIPPEL NEE!

Wat doe je met known issues? Ga je die verstoppen in een excel sheet? Ga je die wegvrotten in Jira? Nee, DIE LOS JE OP!

Iedere minuut die een known issue langer bestaat wordt het lastiger hem op te lossen. Dus als je een known issue tegen komt, dan laat je alles uit je handen vallen en los je de issue op!

Bron: Taiichi Ohno, "The Toyota Way"
(Oh ja, en iedereen die zich ooit serieus bezig gehouden heeft met het proces van software ontwikkeling)

Dus als jij een known issue ziet laat je het werk aan een groter beveiligings issue vallen? Sorry, maar dit is echt niet realistisch.

[Hydra]

Croga schreef op vrijdag 1 december 2017 @ 13:02:
Iedere minuut die een known issue langer bestaat wordt het lastiger hem op te lossen. Dus als je een known issue tegen komt, dan laat je alles uit je handen vallen en los je de issue op!

Wat een onzin.

[Croga]

NMe schreef op vrijdag 1 december 2017 @ 13:11:
[...]

Ben je nou sarcastisch of meen je dit serieus? Er zijn talloze redenen waarom je issues niet acuut oppakt:

1. De issue is niet belangrijk genoeg.
2. De issue is wel belangrijk maar andere dingen zijn nóg belangrijker.
3. De issue kost meer om te fixen dan het zou kosten om ermee te leren leven.
4. De issue kán gewoon niet opgelost worden.
5. De issue komt voort uit veranderde specs en de klant wil niet betalen voor het oplossen.

Een paar van de grootste projecten op het internet hebben duizenden known issues die soms zelfs jarenlang open blijven staan.

Er zijn twee opties:
- De issue moet opgelost worden. Als je dat niet NU doet gaat het veel meer kosten. Nog onafhankelijk van het feit dat code bouwen op kapotte code een enorm slecht idee is.
- De issue hoeft niet opgelost te worden. In dat geval is het zinloos om hem te registreren.

Registratie is ten allen tijde waste. Het is altijd verspilling. Er is geen enkele goede reden om een issue ergens vast te leggen.

- Issue niet belangrijk genoeg? Dan ook niet belangrijk genoeg om vast te leggen.
- Issue wel belangrijk maar iets anders belangrijker? Dat "anders" ben je dus aan het bouwen bovenop kapotte code. Je hebt een garantie dat je de kwaliteit van je product aan het verslechteren bent. Domme zet dus.
- Issue kost meer om te fixen dan leven met het probleem? Nonsense; je hebt kapotte code. De kosten om er mee te leven gaan over tijd onvoorspelbaar stijgen. Je hebt dus geen flauw idee wat er duurder is.
- Issue kan niet opgelost worden? Nonsense; je hebt kapotte code, ga mij niet vertellen dat kapotte code niet te repareren is.
- Issue komt voor uit veranderende spec; Nope. Dan is het geen issue, dan is het andere functionaliteit. Dat noemen we gewoon een product backlog item. Of een feature. Of hoe je het ook wilt noemen.

Let op! We hebben het hier over bugs! Een bug is kapotte code. Een bug is niet "het ding doet iets anders dan ik denk dat het zou moeten doen". Een bug is "Het ding is kapot".
- "Het ding doet iets anders dan ik denk dat het zou moeten doen" is een kwestie van specificaties. Die staan niet tussen "known issues", die staan tussen specificaties
- "Het ding is kapot" is een bug. Die staan nergens, die los je op.

https://dojo.ministryofte...-as-soon-as-you-find-them

Hydra schreef op vrijdag 1 december 2017 @ 13:32:
Wat een onzin.

Wat jij onzin noemt, noemen jaren van research door vooraanstaande programmeurs en wetenschappers feiten:
http://blog.celerity.com/the-true-cost-of-a-software-bug

[ Voor 6% gewijzigd door Croga op 01-12-2017 13:40 ]

[Croga]

.

[ Voor 99% gewijzigd door Croga op 01-12-2017 13:39 ]

[NMe]

Croga schreef op vrijdag 1 december 2017 @ 13:36:
[...]

Er zijn twee opties:
- De issue moet opgelost worden. Als je dat niet NU doet gaat het veel meer kosten. Nog onafhankelijk van het feit dat code bouwen op kapotte code een enorm slecht idee is.
- De issue hoeft niet opgelost te worden. In dat geval is het zinloos om hem te registreren.

Sorry, wat? Soms is het direct oplossen van een bug gewoon geen optie, geen enkel bedrijf heeft oneindig veel tijd en zeker niet oneindig veel geld. Er moeten gewoon keuzes gemaakt worden, en die keuze kan best zijn dat de bug later een keer opgelost moet worden. Kost het dan meer? Mogelijk. Is het daarom meteen onwenselijk? Nee.

- Issue niet belangrijk genoeg? Dan ook niet belangrijk genoeg om vast te leggen.

Natuurlijk wel. Iets dat vandaag niet belangrijk genoeg is, is dat over 2 jaar met nieuw management misschien wel. Krijg je als bedrijf op je flikker omdat je een bug in je systeem hebt zitten omdat je niet hebt geregistreerd dat je klant het probleem niet wilde prioritiseren...

Sorry, maar je geeft er niet bepaald blijk van ooit met klanten gewerkt te hebben.

[Hydra]

Croga schreef op vrijdag 1 december 2017 @ 13:38:
Wat jij onzin noemt, noemen jaren van research door vooraanstaande programmeurs en wetenschappers feiten:

Jij had het over "known issues". Er zijn meer dan genoeg 'known issues' die gewoon in de categorie 'jammer maar nu niet de hoogste prio' vallen. Het spreekt bovendien van weinig ervaring als mensen dergelijk zwart-witte uitspraken doen.

Daarnaast heeft het ook nog eens erg weinig met het onderwerp te maken. De software was verre van 'af'.

[Croga]

NMe schreef op vrijdag 1 december 2017 @ 13:40:
Sorry, wat? Soms is het direct oplossen van een bug gewoon geen optie, geen enkel bedrijf heeft oneindig veel tijd en zeker niet oneindig veel geld. Er moeten gewoon keuzes gemaakt worden, en die keuze kan best zijn dat de bug later een keer opgelost moet worden. Kost het dan meer? Mogelijk. Is het daarom meteen onwenselijk? Nee.

Als je niet oneindig geld hebt dan lijkt het me slim om te zorgen dat je het niet nodeloos weg gooit. Zoals door te wachten met het oplossen van je bugs totdat de prijs voor het oplossen ver-10-voudigt of ver-100-voudigt is.

Natuurlijk wel. Iets dat vandaag niet belangrijk genoeg is, is dat over 2 jaar met nieuw management misschien wel. Krijg je als bedrijf op je flikker omdat je een bug in je systeem hebt zitten omdat je niet hebt geregistreerd dat je klant het probleem niet wilde prioritiseren...

Koel. Als het over 2 jaar wel belangrijk genoeg is dan zie je het over 2 jaar vanzelf weer terug komen. Dan is het zinloos om de bug 2 jaar in een of andere lijst te laten rotten. Die lijst is in 2 jaar tijd dusdanig gegroeid, veroudert, achterhaalt dat de gegevens in die lijst (want informatie is het al lang niet meer) waardeloos, verwarrend en gevaarlijk is.

Sorry maar je geeft er niet bepaald blijk van inzicht te hebben in het software ontwikkel proces (maar laten we vanaf nu de ad-hominems liever achterwege, het voegt zo weinig toe)

[Anoniem: 63072]

Croga schreef op vrijdag 1 december 2017 @ 13:36:
[...]

Er zijn twee opties:
- De issue moet opgelost worden. Als je dat niet NU doet gaat het veel meer kosten. Nog onafhankelijk van het feit dat code bouwen op kapotte code een enorm slecht idee is.
- De issue hoeft niet opgelost te worden. In dat geval is het zinloos om hem te registreren.

Registratie is ten allen tijde waste. Het is altijd verspilling. Er is geen enkele goede reden om een issue ergens vast te leggen.

Ik weet niet in welk fantasie land jij leeft, maar als onze helpdesk melding van een issue krijg, dan registreren wij die in de bug tracker en wordt die geassigned aan een dev. Dat kost minder tijd als naar de dev lopen en het uitleggen en heeft als voordeel dat deze niet gestoord wordt met waar hij op dat moment mee bezig.

Uiteindelijk kan je een issue oplossen en is het letterlijk 1 click om die op resolved te zetten, of hij is niet belangrijk genoeg om op te lossen en je registreert hem omdat je de volgende keer dat je de melding krijgt je geen zin heb om het weer te onderzoeken.

Ik hoop dat ik nooit aan een project hoef te werken waarbij de known issues niet geregisteerd zijn, ik geloof dat ik dan meteen zou gaan soliciteren.

[NMe]

Croga schreef op vrijdag 1 december 2017 @ 13:43:
Sorry maar je geeft er niet bepaald blijk van inzicht te hebben in het software ontwikkel proces (maar laten we vanaf nu de ad-hominems liever achterwege, het voegt zo weinig toe)

Nee, jij bent hier echt heel idealistisch aan het roepen dat je zodra je een fout vindt je alles uit je handen moet laten vallen en acuut die fout op moet lossen. Leuk en aardig maar elk bedrijf dat zo opereert is binnen een jaar failliet omdat ze hun targets niet halen en deadlines missen. Geen van ons vindt het leuk om bugs in zijn code te hebben maar er moet ook geld verdiend worden.

Wat betreft ad hominems, je begon zelf met je ronduit idiote "(Oh ja, en iedereen die zich ooit serieus bezig gehouden heeft met het proces van software ontwikkeling)." Want juist die mensen zijn het daar roerend mee oneens.

[ Voor 14% gewijzigd door NMe op 01-12-2017 13:47 ]

[Croga]

Anoniem: 63072 schreef op vrijdag 1 december 2017 @ 13:44:
Ik weet niet in welk fantasie land jij leeft, maar als onze helpdesk melding van een issue krijg, dan registreren wij die in de bug tracker en wordt die geassigned aan een dev. Dat kost minder tijd als naar de dev lopen en het uitleggen en heeft als voordeel dat deze niet gestoord wordt met waar hij op dat moment mee bezig.

Het resultaat is dat het probleem überhaupt niet uitgelegd wordt en de dev dus geen flauw idee heeft waar hij moet beginnen......

Ik hoop dat ik nooit aan een project hoef te werken waarbij de known issues niet geregisteerd zijn, ik geloof dat ik dan meteen zou gaan soliciteren.

Koel. De afgelopen 10 jaar heb ik niet anders gedaan. Het resultaat was dat, keer op keer, de tijd dat developers bezig waren bugs op te lossen na verloop van tijd kelderde. In één van de projecten van zo'n 20 per maand naar 1 per 3 maanden. Alleen maar door simpelweg de zaken op te lossen in plaats van te registreren. En dit is een patroon wat je terug ziet keren in alle producten waar dit gedaan wordt.

NMe schreef op vrijdag 1 december 2017 @ 13:45:
Nee, jij bent hier echt heel idealistisch aan het roepen dat je zodra je een fout vindt je alles uit je handen moet laten vallen en acuut die fout op moet lossen. Leuk en aardig maar elk bedrijf dat zo opereert is binnen een jaar failliet omdat ze hun targets niet halen en deadlines missen. Geen van ons vindt het leuk om bugs in zijn code te hebben maar er moet ook geld verdiend worden.

Wederom een uitspraak die geen grond kent.
Alle bedrijven en teams die ik ken die dit patroon inzetten versnellen hun waardecreatie. Wellicht is mijn uitspraak idealistisch maar dat is met reden; deze manier van werken heeft zich honderden zoniet duizenden keren bewezen. Waar een developer normaal 30-50 procent van zijn tijd bezig is met problemen oplossen, zorgt deze manier van werken er voor dat hij in plaats daarvan bezig kan zijn met waarde creëeren. Met targets halen (in plaats van alleen op papier), met deadlines halen (in plaats van leugens verkondigen) Met geld verdienen! Maar dan echt.

Als je begint met serieus om te gaan met software kwaliteit dan hoef je plots na live-gang geen half jaar meer bezig te zijn met gratis werken en kun je dus gewoon verder met nóg meer geld verdienen. Dit is geen ideologie, die zijn keiharde verbeterpunten die heel even pijn doen en dan plots zorgen voor grotere kwaliteit, grotere betrouwbaarheid, grotere voorspelbaarheid. Allemaal zaken die simpelweg geld opleveren.

[ Voor 39% gewijzigd door Croga op 01-12-2017 13:51 ]

[AW_Bos]

Croga schreef op vrijdag 1 december 2017 @ 13:36:
Let op! We hebben het hier over bugs! Een bug is kapotte code. Een bug is niet "het ding doet iets anders dan ik denk dat het zou moeten doen". Een bug is "Het ding is kapot".

Sorry, maar mag ik zeggen dat ik dit ook onzin vind.

De beschrijving van een bug is:

Een bug is een fout in een computerprogramma of een website, waardoor het zijn functie niet (geheel) volgens specificaties vervult. Praktisch alle programma's van enige omvang bevatten bugs, maar de meeste worden niet als storend ervaren of treden alleen onder zeldzame omstandigheden op.

Dus als mijn applicatie 'a' in de database zet, maar per ongeluk toch 'b' erin zet en gewoon netjes zijn werk uitvoert. Dan is dat dus volgens jou geen bug?

Een 'known issue' staat toch echt bij een goed project in een versiebeheersysteem (Mantis, Jira whatever) omschreven met een proriteit. Aan de hand hiervan is duidelijk of het direct opgelost moet worden, en of het misschien kan wachten.

[ Voor 12% gewijzigd door AW_Bos op 01-12-2017 13:50 ]

[NMe]

Croga schreef op vrijdag 1 december 2017 @ 13:47:
[...]

Het resultaat is dat het probleem überhaupt niet uitgelegd wordt en de dev dus geen flauw idee heeft waar hij moet beginnen......

Dan is je eerstelijns-support onbekwaam.

Koel. De afgelopen 10 jaar heb ik niet anders gedaan. Het resultaat was dat, keer op keer, de tijd dat developers bezig waren bugs op te lossen na verloop van tijd kelderde. In één van de projecten van zo'n 20 per maand naar 1 per 3 maanden. Alleen maar door simpelweg de zaken op te lossen in plaats van te registreren. En dit is een patroon wat je terug ziet keren in alle producten waar dit gedaan wordt.

Ja, dat komt vást omdat je de bugs niet registreert en heeft er niks mee te maken dat er na verloop van tijd minder bugs in elk project zitten. Daarnaast betekent registratie niet dat je bugs niet oppakt, het betekent dat je ze op afgesproken tijden op de roadmap zet.

Croga schreef op vrijdag 1 december 2017 @ 13:47:
Wederom een uitspraak die geen grond kent.
Alle bedrijven en teams die ik ken die dit patroon inzetten versnellen hun waardecreatie. Wellicht is mijn uitspraak idealistisch maar dat is met reden; deze manier van werken heeft zich honderden zoniet duizenden keren bewezen. Waar een developer normaal 30-50 procent van zijn tijd bezig is met problemen oplossen, zorgt deze manier van werken er voor dat hij in plaats daarvan bezig kan zijn met waarde creëeren. Met targets halen (in plaats van alleen op papier), met deadlines halen (in plaats van leugens verkondigen) Met geld verdienen! Maar dan echt.

Als je begint met serieus om te gaan met software kwaliteit dan hoef je plots na live-gang geen half jaar meer bezig te zijn met gratis werken en kun je dus gewoon verder met nóg meer geld verdienen. Dit is geen ideologie, die zijn keiharde verbeterpunten die heel even pijn doen en dan plots zorgen voor grotere kwaliteit, grotere betrouwbaarheid, grotere voorspelbaarheid. Allemaal zaken die simpelweg geld opleveren.

...

Goed. Je bent een development-toko. Je hebt een groot project waarvan de klant melding doet van 5 verschillende, grote bugs (volgens de echte definitie "werkt niet volgens specificatie") die elk twee weken kosten om goed op te lossen. Je hebt slechts 4 developers beschikbaar die er iets mee kunnen gaan doen. Wat doe je met de vijfde bug? Registreren is volgens jou een waste of time. Prioriteit heb je bovendien nergens gelogd. Urenregistratie moet allemaal buiten een koppeling met een daadwerkelijk issue om. Dit soort workflow is gewoon vragen om problemen en het is echt belachelijk dat je dat 1) niet inziet en 2) iedereen die het met je oneens is verwijt "niet serieus bezig te zijn met softwarekwaliteit." Ik vind dat stuitend.

[ Voor 48% gewijzigd door NMe op 01-12-2017 13:55 ]

[Croga]

NMe schreef op vrijdag 1 december 2017 @ 13:50:
Dan is je eerstelijns-support onbekwaam.

Bullshit.
Opschrijven van zaken is de allerslechtste vorm van communicatie. Zo'n 95% van de informatie gaan verloren bij het vastleggen. Again; geen idealistische praat, gewoon zaken die we al jaren onderzoeken en bewijzen. De uitspraak "Als jij het niet op papier kunt overdragen ben je onbekwaam" is een hele flauwe en zwakke manier om aan te geven dat we "human nature" liever negeren als het ons niet uit komt.

Ja, dat komt vást omdat je de bugs niet registreert en heeft er niks mee te maken dat er na verloop van tijd minder bugs in elk project zitten. Daarnaast betekent registratie niet dat je bugs niet oppakt, het betekent dat je ze op afgesproken tijden op de roadmap zet.

Het betekend dat je tijd en kennis weg gegooid hebt aan registratie in plaats van de zaken gewoon op te lossen.

[downtime]

Croga schreef op vrijdag 1 december 2017 @ 13:36:
[...]

- De issue hoeft niet opgelost te worden. In dat geval is het zinloos om hem te registreren.

Onzin. Je wilt registreren omdat je naar elke issue wil kijken, impact bepaalt, inschat hoeveel het kost om op te lossen, en als je besluit om het (voorlopig) niet op te lossen dan wil je dat ook vastleggen zodat je niet andermaal dezelfde effort in dezelfde issue steekt als een ander tester/gebruiker die volgende maand opnieuw meldt.

[Croga]

downtime schreef op vrijdag 1 december 2017 @ 13:54:
Onzin. Je wilt registreren omdat je naar elke issue wil kijken, impact bepaalt, inschat hoeveel het kost om op te lossen, en als je besluit om het (voorlopig) niet op te lossen dan wil je dat ook vastleggen zodat je niet andermaal dezelfde effort in dezelfde issue steekt als een ander tester/gebruiker die volgende maand opnieuw meldt.

Het eerste deel van je betoog heet Triage. Daarvoor hoef je niets vast te leggen.
Het tweede deel van je betoog is levensgevaarlijk. Wat nu als je denkt hetzelfde gevonden te hebben en het blijkt toch net iets anders te zijn? (om nog maar te zwijgen over het feit dat het in de praktijk simpelweg niet zo werkt; we hebben dat ooit "kennis management" genoemd en onderzoek wijst al jaren uit dat dat niet werkt; die vastgelegde lijst wordt niet geraadpleegd. Waarom niet? Omdat triage om te zien of het al vastgelegd is net zo veel werk is als triage om te kijken of het opgelost moet worden)

[NMe]

Croga schreef op vrijdag 1 december 2017 @ 13:54:
[...]

Bullshit.
Opschrijven van zaken is de allerslechtste vorm van communicatie.

Right. Dus jij hebt liever face to face uitleg met daarbij alle interpretatieverschillen van dien? Waarbij, zeker bij issues die langer duren om te fixen, na verloop van tijd dingen vergeten of verkeerd onthouden worden? Op een manier waarop je de klant niet kan wijzen op zijn eigen opdracht als hij na 2 maanden aankomt met "waarom de fuck werkt het zo" terwijl hij daar zelf om gevraagd heeft?

Het betekend dat je tijd en kennis weg gegooid hebt aan registratie in plaats van de zaken gewoon op te lossen.

Dit kan je niet echt geloven. Hoe ben jij in hemelsnaam nog niet totaal uitgekleed door een klant die beweert dat jij je afspraken niet nakomt omdat je ze niet documenteert?

[Anoniem: 63072]

Croga schreef op vrijdag 1 december 2017 @ 13:54:
[...]

Bullshit.
Opschrijven van zaken is de allerslechtste vorm van communicatie.

Steps to recreate:

1. ...

Het enige deel van een bugmelding dat ik echt nodig heb. Als die er zijn is het probleem 100% gecommuniceerd.

De echt lastige bugs zijn degene die niet consistent te reproduceren zijn, daar wordt zoveel mogelijk info bij gezet en heb het al genoeg gezien dat er na meerdere meldingen een patroon ontstaat waardoor je het toch op kan lossen.

Veel succes daarmee als je niets registreert.

Met die houding lig je er bij ons na een dag uit.

NMe schreef op vrijdag 1 december 2017 @ 13:59:
[...]
Dit kan je niet echt geloven. Hoe ben jij in hemelsnaam nog niet totaal uitgekleed door een klant die beweert dat jij je afspraken niet nakomt omdat je ze niet documenteert?

Ik kan me er wel iets bij voorstellen, hoor het (te) vaak bij startups die een nieuwe webdienst de grond uit aan het stampen zijn. Release early, release often en de shit lossen we wel op als we gebruikers hebben.

Als je dan weggaat bij de startup voor die de maturity bereikt waarbij het gebrek aan documentatie je gaat opbreken, blijf je in de waan dat je bugs kan negeren.

[ Voor 32% gewijzigd door Anoniem: 63072 op 01-12-2017 14:10 ]

[Croga]

NMe schreef op vrijdag 1 december 2017 @ 13:59:
Right. Dus jij hebt liever face to face uitleg met daarbij alle interpretatieverschillen van dien? Waarbij, zeker bij issues die langer duren om te fixen, na verloop van tijd dingen vergeten of verkeerd onthouden worden? Op een manier waarop je de klant niet kan wijzen op zijn eigen opdracht als hij na 2 maanden aankomt met "waarom de fuck werkt het zo" terwijl hij daar zelf om gevraagd heeft?

Dit kan je niet echt geloven. Hoe ben jij in hemelsnaam nog niet totaal uitgekleed door een klant die beweert dat jij je afspraken niet nakomt omdat je ze niet documenteert?

Die laatste vraag is enorm eenvoudig te beantwoorden: Vertrouwen en acceptatie. Ten eerste vertrouw ik de klant en vertrouwd de klant mij. Is dat vertrouwen er niet, doe ik geen zaken. Ten tweede accepteerd de klant alles wat we samen realiseren (Ja! Samen!). En omdat mijn klant weet dat ik een bug oplos, weet de klant ook dat de kwaliteit van de software buiten kijf staat. Dit in tegenstelling tot andere leveranciers die kwaliteit niet zo heel erg nauw nemen.

Die eerste vraag is ook heel eenvoudig; je komt niet na 2 maanden aan zetten omdat ieder stuk functionaliteit tot in detail door de klant zelf in gebruik genomen is. Iedere 2 weken weer. En iedere 2 weken heeft de klant aan kunnen geven dat er details anders moeten en dan zijn die details 2 weken later ook anders.

Overigens heb je het over interpretatie verschillen in face to face uitleg. En daarmee bewijs je mijn punt: Die interpretatieverschillen zijn er altijd. Of je het nou opschrijft of verteld. Echter kun je ze bij geschreven text niet mitigeren; de verschillen zijn de verschillen en zullen lijden tot een non-oplossing van de non-bug. Face to face kun je ze bespreken zodat ze verdwijnen.

[Croga]

Anoniem: 63072 schreef op vrijdag 1 december 2017 @ 14:06:
Met die houding lig je er bij ons na een dag uit.

Koel. Nog zo'n bedrijf wat over 10 jaar niet meer bestaat.....

[orf]

Croga schreef op vrijdag 1 december 2017 @ 13:02:
[...]

Nee. Dubbel Nee! TRIPPEL NEE!

Wat doe je met known issues? Ga je die verstoppen in een excel sheet? Ga je die wegvrotten in Jira? Nee, DIE LOS JE OP!

Iedere minuut die een known issue langer bestaat wordt het lastiger hem op te lossen. Dus als je een known issue tegen komt, dan laat je alles uit je handen vallen en los je de issue op!

Bron: Taiichi Ohno, "The Toyota Way"
(Oh ja, en iedereen die zich ooit serieus bezig gehouden heeft met het proces van software ontwikkeling)

Er zit een render-bug in je homepage in de linkerkolom. Kan me niet voorstellen dat je die niet gezien hebt en niet hebt opgelost.

[Croga]

Motrax schreef op vrijdag 1 december 2017 @ 14:14:
Misschien omdat Croga in een heel klein team werkt waar iedereen senior is en al jaren op het product werkt. Dan zou het kunnen werken.

Ja, klein team, nee, geen "seniors" (dat concept heeft geen waarde met een gebalanceerd team wat swarmed), nee geen jaren op het product.

Wat ik wel doe is mijn vak serieus nemen en dus continue kijken naar wat er aan serieus onderzoek met serieuze conclusies is. Zoals http://stevemcconnell.com...are-quality-at-top-speed/ en http://scrumbook.org/value-stream/good-housekeeping.html . Met als resultaat dat de successen van mijn teams zorgen dat ik serieus genomen wordt.

Even terugkomend op het onderwerp, een naïve vraag: waarom zijn ze niet heel klein begonnen en hebben ze niet eerst de bestaande functionaliteit 1:1 overgenomen en in een moderner jasje gestoken? Wel met een architectuur waardoor er nieuwe functionaliteit bij kan komen?

Omdat de overheid dat niet mag. Er moet een gedetailleerd bestek zijn voor een aanbesteding. Ik ben het met je eens dat een serieus incrementele implementatie in alle gevallen de enige serieuze optie is maar dat is met de huidige aanbestedings wetgeving heel erg moeilijk te bereiken.

[Hydra]

Motrax schreef op vrijdag 1 december 2017 @ 14:14:
Misschien omdat Croga in een heel klein team werkt waar iedereen senior is en al jaren op het product werkt. Dan zou het kunnen werken.

Ik werk in een klein team met vrijwel altijd seniors en er zijn hier genoeg lastige issues die meestal geen groot probleem opleveren maar wel een 'probleem' zijn die op de backlog staan. Vind het vooral gelul (niet van jou, van Croga).

Verder is dit over die known issues gewoon echt gelul in de ruimte. Die software was bij lange na niet in productie; die sheet was gewoon een lijstje met todo's die iemand een keer opgesteld had, hoogst waarschijnlijk vanuit het ticketing systeem. Waarschijnlijk niet eens up to date dus. Dus deze hele fittie over 'known issues' is vooral heel erg treurig en je ziet dat een aantal mensen hier nog nooit op een dergelijk groot overheidsproject gewerkt hebben.

[Question Mark]

Croga schreef op vrijdag 1 december 2017 @ 13:47:
[...]
Het resultaat was dat, keer op keer, de tijd dat developers bezig waren bugs op te lossen na verloop van tijd kelderde. In één van de projecten van zo'n 20 per maand naar 1 per 3 maanden

Waar is die rapportage op gebasseerd? Gewoon even een vraag... aangezien jij je bugs nergens registreerd of bijhoudt...

Concreet zeg je hier dat sinds je gestopt bent met registreren met bugs het aantal bugs is teruggelopen. Zo lust ik er nog wel een paar...

[ Voor 14% gewijzigd door Question Mark op 01-12-2017 14:54 ]

[MuddyMagical]

Croga schreef op vrijdag 1 december 2017 @ 14:20:
[...]

Ja, klein team, nee, geen "seniors" (dat concept heeft geen waarde met een gebalanceerd team wat swarmed), nee geen jaren op het product.

Wat ik wel doe is mijn vak serieus nemen en dus continue kijken naar wat er aan serieus onderzoek met serieuze conclusies is. Zoals http://stevemcconnell.com...are-quality-at-top-speed/ en http://scrumbook.org/value-stream/good-housekeeping.html . Met als resultaat dat de successen van mijn teams zorgen dat ik serieus genomen wordt.

[...]

Omdat de overheid dat niet mag. Er moet een gedetailleerd bestek zijn voor een aanbesteding. Ik ben het met je eens dat een serieus incrementele implementatie in alle gevallen de enige serieuze optie is maar dat is met de huidige aanbestedings wetgeving heel erg moeilijk te bereiken.

Leuk als je met 4 man op een kamer zit, maar elke iets grotere organisatie heeft hier echt niks aan.

Dit gaat echt lekker werken als de SD in India mij voor elke scheet gaat bellen om uit te leggen dat ze een bug hebben gevonden. Ik heb hier 275.000 eindgebruikers rondlopen en ongeveer 600 man 1e lijn support. Die mogen het dus echt wel even registreren zodat we een normale lijst hebben waarbij we de prioriteit kunnen bepalen want als ze elke keer mijn team bellen dan gebeurt er helemaal niks meer.

Trouwens, wel sterk van je dat je ondanks alle tegenspraak gewoon doorgaat!

[Anoniem: 27535]

Croga schreef op vrijdag 1 december 2017 @ 14:20:
[...]

Ja, klein team, nee, geen "seniors" (dat concept heeft geen waarde met een gebalanceerd team wat swarmed), nee geen jaren op het product.

Wat ik wel doe is mijn vak serieus nemen en dus continue kijken naar wat er aan serieus onderzoek met serieuze conclusies is. Zoals http://stevemcconnell.com...are-quality-at-top-speed/ en http://scrumbook.org/value-stream/good-housekeeping.html . Met als resultaat dat de successen van mijn teams zorgen dat ik serieus genomen wordt.

[...]

Omdat de overheid dat niet mag. Er moet een gedetailleerd bestek zijn voor een aanbesteding. Ik ben het met je eens dat een serieus incrementele implementatie in alle gevallen de enige serieuze optie is maar dat is met de huidige aanbestedings wetgeving heel erg moeilijk te bereiken.

Ik begrijp je insteek, maar de reden dat je zo veel weerstand krijgt is dat je geen enkele realiteitszin laat zien of laat blijken dat je kennis hebt van enige andere (commerciële) processen. De discussie is op deze manier zinloos omdat je toch vanuit je toren blijft roepen wat alleen mogelijk is omdat je alle andere factoren uitsluit.

Je beroept je op jaren ervaring en doet claims over bedrijven die niet meer zullen bestaan. Precies zo zwart-wit. Je doet me denken aan iemand bij ons op een gegeven moment een aantal jaar de lead voor development deed, en er was nooit een marketready product. Bij het eind van component B waren er nieuwe inzichten voor component A, dus dat moest wel gelijk verbeterd worden.

Je jaren ervaring met het bijhouden van de spullen van de lokale korfbalvereniging werken daar vast prima, maar ga alsjeblieft niet dit soort houding en standpunten rondstrooien richting enige serieuze software-ontwikkelaar.

Als je wil weten of ik de impact besef van problemen bij de klant en gevolgen van een slechte klantervaring, pak de research uit m'n sig: dat is het meest uitgebreide en onderbouwde stuk onderzoek over klantcommunicatie en ervaring, geschreven door mijn team. Wij doen dat voor een van 's werelds grootste spelers in software voor bedrijfsprocessen en klantcommunicatie.

[ Voor 8% gewijzigd door Anoniem: 27535 op 01-12-2017 14:55 ]

[Ealanrian]

Croga schreef op vrijdag 1 december 2017 @ 13:36:
[...]

Er zijn twee opties:
- De issue moet opgelost worden. Als je dat niet NU doet gaat het veel meer kosten. Nog onafhankelijk van het feit dat code bouwen op kapotte code een enorm slecht idee is.
- De issue hoeft niet opgelost te worden. In dat geval is het zinloos om hem te registreren.

Registratie is ten allen tijde waste. Het is altijd verspilling. Er is geen enkele goede reden om een issue ergens vast te leggen.

Er zijn ook vakgebieden waar Alles, maar dan ook echt alles gerelateerd moet zijn aan requirements of bug reports in verband met safety critcal systems. Als er een implementatie fout gevonden word moet deze gemeld en geregistreerd worden. Ook omdat de gene die de fout vind geen contact heeft met de gene die de fout moet oplossen maar ook omdat een test team van tientallen testers nou eenmaal veel fouten kunnen vinden in verschillende systemen. En om nou al die testers te introduceren bij tientallen ontwikkel teams en dus honderden software engineers maakt het op zijn minst uitdagend om fouten uberhaupt op te lossen zonder ze te registreren.

Met andere woorden, wat je hier verkondigt en predikt alsof het de heilige graal van ontwikkelprocessen is gaat gewoon niet werken in alle situaties.

[Cloud]

Croga schreef op vrijdag 1 december 2017 @ 15:08:
[...]
Feit blijft dat alle onderzoek wat gedaan wordt naar software kwaliteit en de invloed daarvan op snelheid van leveren uitwijst dat er maar één optie is voor bugs en dat is onmiddelijk oplossen.

Het is wel jammer dan dat verschillende branches van software ontwikkeling dus gegarandeerd nooit kwaliteit kunnen gaan leveren in jouw ogen, omdat certificering ze verplicht alles te registreren. Ik snap ook niet hoe er aan risico inschatting gedaan kan worden als je niets registreert en dus elke ontwikkelaar als lone gunman door de code wandelt. Of hoe management weet wanneer dingen klaar kunnen zijn. Of hoe je voorkomt dat je nog ergere bugs maakt (één oplossen, een ergere ervoor in de plaats krijgen vanwege gebrekkige impact analyses). Als je niets registreert moet alle verantwoordelijkheid wel bij de ontwikkelaar liggen; ik ben blij dat ik niet zo'n ontwikkelaar hoef te zijn.

Ik vind het een prachtig verhaal en wellicht werkt het in startups met kleine teams van seniors; ik zie het echter nergens anders werken.

[Question Mark]

Cloud schreef op vrijdag 1 december 2017 @ 15:20:
[...]
Ik vind het een prachtig verhaal en wellicht werkt het in startups met kleine teams van seniors; ik zie het echter nergens anders werken.

Ik heb er in alle eerlijkheid even naar gezocht, maar ik kom wel het volgende tegen:

Managing Bugs in Scrum and Agile Projects

Ik ben zelf ook onderdeel in een scrumteam (niet als ontwikkelaar overigens), en wij plaatsen bugs "gewoon" op de backlog maar ik moet zeggen dat het bovenstaande verhaal in sommige gevallen mij best wel werkbaar lijkt te zijn.

[Cloud]

@Question Mark
Oh ik zie het ook wel werken hoor. Maar ik zie het niet als de altijd toepasbare heilige graal zoals dit nu gepresenteerd wordt. Er zijn wel een paar settings waarin het werkbaar is denk ik. Maar dat zie ik dan vooral in startup fases, voor compleet nieuwe software die nog niet 'live' draait. Of de ontwikkelfase van nieuwe functionaliteiten binnen bestaande software. De prototype fase zo je wilt

[Harrie_]

Question Mark schreef op vrijdag 1 december 2017 @ 15:27:
[...]

Ik heb er in alle eerlijkheid even naar gezocht, maar ik kom wel het volgende tegen:

Managing Bugs in Scrum and Agile Projects

Ik ben zelf ook onderdeel in een scrumteam (niet als ontwikkelaar overigens), en wij plaatsen bugs "gewoon" op de backlog maar ik moet zeggen dat het bovenstaande verhaal in sommige gevallen mij best wel werkbaar lijkt te zijn.

Ik zie in dat artikel het volgende staan:

• Team member (the discoverer) finds a bug and finds who wrote that bit of code (the originator).
• The discoverer gets up, goes to the originator (if they are not already working together) and says “I’ve found a bug in some code you wrote—let’s fix it together.”
• The originator immediately stops working on whatever they were working on and the offender and the discoverer work together to fix the bug.

En dan heb je te maken met een applicatie die al 15 jaar 'evolutie' heeft doorgemaakt, ramvol legacy code geschreven door ontwikkelaars die allang vertrokken zijn... succes

Wat een topic trouwens is er ook popcorn?

[Onbekend]

Interessant topic.

Bugs nooit direct oplossen, tenzij het een typfoutje/vertaalfoutje is.
Het is namelijk mogelijk dat een stukje software vanwege die bug juist gunstig werkt, of zelfs een ergere bug verbergt.

De bug gewoon noteren en een kleine uitleg erbij maken (schermprintjes met 1 regel tekst zijn vaak voldoende). Vervolgens overleg je over de urgentie van dat punt en laat je dit inplannen. Het moet later namelijk toch weer getest worden en als bugfix geregistreerd worden.
Ook als de code nog nieuw is en nog niet bij een klant draait moet je kijken hoeveel tijd het kost om die bug op te lossen en of dat nog wel in de planning past.

Software met bugs uitleveren is niet erg, maar zomaar aanpassingen in code doen zonder dat dat ergens wordt genoteerd is erger.

[whoami]

Bugs moet je registreren zodanig dat je een track hebt. Als iemand nadien nog eens eenzelfde bug rapporteert kan je zo ook weten of die user moet upgraden naar een nieuwere versie, of als je een regression bug hebt (liever niet, want de testen die je gemaakt hebt bij het oplossen van de bug zouden dit opnieuw moeten opvangen).

Eens de bug geregistreerd is, kan die opgenomen worden in een sprint om opgelost te worden. Bij het inplannen van een sprint worden bugs & features uit de backlog gepicked. Bij de start van de sprint vind ik dan wel dat de ingeplande bugs het eerst moeten opgepakt worden.

[downtime]

Question Mark schreef op vrijdag 1 december 2017 @ 15:27:
[...]

Ik heb er in alle eerlijkheid even naar gezocht, maar ik kom wel het volgende tegen:

Managing Bugs in Scrum and Agile Projects

Ik ben zelf ook onderdeel in een scrumteam (niet als ontwikkelaar overigens), en wij plaatsen bugs "gewoon" op de backlog maar ik moet zeggen dat het bovenstaande verhaal in sommige gevallen mij best wel werkbaar lijkt te zijn.

Naar aanleiding van die link ben ik ook wat anders naar het verhaal van Croga gaan kijken. Hij is in elk geval geen goede pleitbezorger van de methode die hij voorstaat. Context is belangrijk en in dit geval werkt zijn methode eigenlijk alleen in een context waarbij nieuwe code wordt gebouwd en bugs worden gevonden door een tester die voor hetzelfde project werkt en die korte lijntjes met de ontwikkelaars heeft. Registratie is dan ook niet nodig omdat die code niet eens vrijgegeven is aan de buitenwereld.

Ik ben zeker een grote fan van het principe "de vervuiler betaald". Ik geloof ook dat fouten (waar mogelijk) hersteld moeten worden door degene die ze gemaakt heeft. Op die manier leert ie ook van zijn fouten. En in deze context, waar de code net geschreven is, is de kans groot dat ie maar een half woord nodig heeft om te weten waar de fout zit.

Maar context telt en deze methode werkt niet meer zodra het project "af" is en gebruikers wereldwijd die code in handen krijgen. Wil je echt shippen naar miljoenen klanten, duizenden meldingen van dezelfde bug terug krijgen, en dan je ontwikkelaars elke keer naar bugs laten kijken die weken geleden al zijn gefixt maar dat wist je niet want niemand heeft iets vastgelegd en de fix is nog niet gedistribueerd.

Dus zal het proces in die situatie anders moeten werken. Iemand zal de meldingen moeten verzamelen, testen of ze gereproduceerd kunnen worden, en die duizenden inzendingen relateren aan een nette rapportage die bruikbare informatie voor een developer bevat. En er moet geprioriteerd worden: Een crash van de applicatie is ernstiger dan een spelfout in een tekst. En dan heb je alsnog iets nodig om issues te tracken.

[Hydra]

Harrie_ schreef op zondag 3 december 2017 @ 17:40:
En dan heb je te maken met een applicatie die al 15 jaar 'evolutie' heeft doorgemaakt, ramvol legacy code geschreven door ontwikkelaars die allang vertrokken zijn... succes

Sowieso: er zit een heel stuk tussen een bug vinden en ook de oorzaak vinden. Als een PO van ons een bug vindt, weet 'ie vrijwel zeker niet in welk deel van de code het zit. Alleen het vinden ervan kan al behoorlijk wat tijd kosten.

Ik vind het altijd erg jammer als dat soort verhalen gebaseerd zijn op rare utopische projecten waar er wel bug zijn maar dat je dan ook meteen de oorzaak gevonden hebt, en ze ook nog eens daadwerkelijk gefixt kunnen worden.

[Haan]

Bij mij gaat het als volgt (middelgroot project, zes scrum teams): bugs die gevonden worden bij pbi's in de huidige sprint worden zoveel mogelijk binnen de sprint opgelost. Uiteraard worden ze wel gewoon geregistreerd op het scrum bord. Het kan ook gebeuren dat een bug een symptoom is van een groter onderliggend probleem, dat zal dan in een volgende sprint opgepakt gaan worden.

[EfBe]

Croga schreef op vrijdag 1 december 2017 @ 13:54:
[...]

Bullshit.
Opschrijven van zaken is de allerslechtste vorm van communicatie. Zo'n 95% van de informatie gaan verloren bij het vastleggen. Again; geen idealistische praat, gewoon zaken die we al jaren onderzoeken en bewijzen. De uitspraak "Als jij het niet op papier kunt overdragen ben je onbekwaam" is een hele flauwe en zwakke manier om aan te geven dat we "human nature" liever negeren als het ons niet uit komt.

[...]

Het betekend dat je tijd en kennis weg gegooid hebt aan registratie in plaats van de zaken gewoon op te lossen.

Sorry, maar hoe ga jij je bugomschrijvingen dan opschrijven? Of spreek je een wav-je in?

- Issues leg je vast in een tracker. Beschrijf ze zo uitvoerig mogelijk, want alles wat je niet beschrijft kun je later wellicht nodig hebben. Als je een repro hebt, meldt die er bij of verwijs naar bv een falende test. Indien er een discussie is bv op een forum, voeg een link toe aan de issue naar die discussie
- Issues worden ingeplanned naar dringendheid. Je kunt niet alles meteen oplossen. Maar ookal los je het meteen op, je legt het toch eerst vast. Je gaat de issue oplossen wanneer dat kan, maar mijn ervaring is dat issues die je 'meteen' kunt fixen op 1 hand te tellen zijn. Veelal zijn bugs minder simpel dan je denkt, of heb je bv architectuurwijzigingen nodig om de issue te fixen. Het kost ook vaak gewoon tijd, bv eerst research doen waarom het optreedt, dan een goede oplossing ontwerpen en die inbouwen. Wanneer je een issue hebt opgeslagen en ingeplanned, dan kun je ook bv de volgende dag verder gaan of 2 dagen later: er gaat geen info verloren.
- Wanneer je de issue hebt gefixed en getest met een nieuwe test die nu slaagt en voorheen niet, commit je de wijzigingen en verwijs je naar de issue(s) die gefixed zijn in de commitmessage. Met een goed systeem leg je dan een link in je VCS naar je issue tracker en vice vesa, dus als je naar je issue kijkt in je systeem dan kun je de wijzigingen zien. Dit is niet moeilijk op te zetten, ikzelf gebruik al jaren Jira + svn en een plugin om in jira de commits te zien die aan issues hangen. Werkt prima.

Jouw manier van hoe mensen moeten werken is absurd, en het zou goed zijn dat mensen die alleen deze thread lezen, zich realizeren dat het in de praktijk gewoon veel beter kan en ook gaat.

Ik ben zo'n 23 jaar professioneel software engineer en heb de invoering van bugtrackers etc. van het begin meegemaakt. In den beginne hadden we waar ik toen werkte helemaal geen issue tracker: de accountmanagers kwamen wat roepen wanneer iets niet werkte of de helpdesk riep wat, iemand schreef dat dan op papier op en er kwam ooit wel eens een wijziging.

Dat werkte voor geen ene meter, omdat niets terug te leiden was naar iets testbaars of naar stukken code die gewijzigd zijn. Met de huidige systemen is dat wel het geval. Ik kan nl zien wanneer een regel is gewijzigd voor een bugfix, dat is nl. via svn en jira gemakkelijk terug te herleiden. Dat is belangrijk want als je die regel weer moet wijzigen voor bv een nieuwe feature weet je dat wanneer een test faalt waarom dat is.

In jouw houtje-touwtje doe-maar-wat-joh 'methodiek' is dat niet het geval. Professionals maken geen software op jouw manier, althans dat zouden ze niet moeten doen.

[Gomez12]

Tja, ik denk dat Croga gewoon ietwat andere definities hanteert dan menig andere devver hier. Waardoor zijn verhaal voor hem wel logisch is.

Want het principe van Croga kan wel werken voor code geschreven binnen 1 a 2 sprints en waarbij je bug definieert als een echt compleet brekend iets.
Dan kan je binnen die sprint nog even de originele devver erbij halen en die het laten oplossen.
En omdat het een echt compleet brekend iets is, daarom moet het ook op korte termijn gefixed worden.

Terwijl dit compleet mank gaat als je dus ook oudere code gaat krijgen (veel plezier met originele devver erbij zoeken van iets wat 2 jaar geleden geschreven is en dan even aan hem vragen of hij kan overzien waar zijn code momenteel al inzit en waar er al om de bug heen geprogrammeerd is)
En het gaat ook compleet mank als je de reguliere definitie van bug gaat hanteren, want die is veel groter en dan ben je veel en veels te veel met zijdingen bezig.

[Hydra]

Gomez12 schreef op maandag 4 december 2017 @ 11:54:
Want het principe van Croga kan wel werken voor code geschreven binnen 1 a 2 sprints en waarbij je bug definieert als een echt compleet brekend iets.

Hij had het niet over "bugs" laat staan "bugs die de app compleet breken". Dat die laatste zsm gefixt worden met een hotfix is evident. Hij had het over "known issues" en stelde dat je voor elke known issue alles laat vallen en het meteen fixt.

De titel (van de mod) van het topic slaat dus de plak wat betreft de oorsprong van de discussie finaal mis. Als hij alleen gesteld had dat ernstige bugs z.s.m. gefixt moesten worden hadden we deze hele discussie niet gehad.

[Edwin88]

Volgens mij is iedereen het met elkaar eens, behalve Croga. Ben heel benieuwd waar hij werkt en hoe ze daar omgaan met bugs

[Hydra]

Edwin88 schreef op dinsdag 5 december 2017 @ 14:00:
Volgens mij is iedereen het met elkaar eens, behalve Croga. Ben heel benieuwd waar hij werkt en hoe ze daar omgaan met bugs

Hij's geen software engineer, nuff said.

[NMe]

Ik heb net weer even twee reacties verwijderd (en nog even getwijfeld over de reactie hier direct boven). Nou ben ik het ook niet met Croga eens maar zullen we hem eens niet op de persoon aanvallen maar gewoon ouderwets op zijn argumenten?

[Tarkin]

Back ontopic dan.

Wat doe je met een legacy product dat aangekocht is? Natuurlijk testloos en ongedocumenteerd (en nee, je mag het aankoop team niet benaderen met cactussen).

Bugs zijn hard to reproduce en kunnen heel veel tijd kosten. Ga je dan ook voor kleine bugs die aanpak doen? A.k.a. de bugs oplossen die weinig value hebben om opgelost te worden?

[downtime]

Tarkin schreef op dinsdag 5 december 2017 @ 22:30:
Wat doe je met een legacy product dat aangekocht is? Natuurlijk testloos en ongedocumenteerd (en nee, je mag het aankoop team niet benaderen met cactussen).

Eerlijk gezegd, als software (source code) zomaar zonder testen en documentatie wordt aangekocht, zonder input van mensen die er wel verstand van hebben, dan heb je als bedrijf wel grotere problemen dan de vraag hoe je met bugs omgaat. Dan zou ik op zoek gaan naar een werkgever die over 5 jaar niet failliet is door wanbeleid.

[Peter]

Degelijk ontworpen software heeft verschillende componenten. Dat kunnen volledig losse systemen zijn, maar ook onderscheid van functionaliteit tussen verschillende bestanden of zelfs functies in hetzelfde bestand creëert dat effect.

Als ik een foutje in de weergave van een menu tegenkom terwijl ik bezig ben met een routine om data te importeren dan is de context switch tussen de twee soorten code duurder dan het summier opschrijven van het probleem.

In grotere projecten zullen zulke disciplines vaak door verschillende personen ingevuld worden—specialisatie. In dat geval ben ik mogelijk niet eens op de hoogte van het menu component, de afwegingen in het ontwerp, de veranderingen die nog in aanbouw zijn of hoe het getest wordt (regressietesten!). Misschien moet het halve menu opnieuw geschreven worden om de fout juist op te lossen.

Stel dat ik het probleem toch oplos, en hier zélf een fout in maak. Dan zit je al met een situatie waarin het niet meer triviaal is om uit te zoeken waar het mis gegaan is. Een tester stelt vast dat er nog steeds een probleem is op het moment dat mijn verandering teruggedraaid wordt.

Tenslotte zegt een probleem in het menu helemaal niets over de kwaliteit van mijn routines.

Dit soort problemen worden alleen maar groter zodra het team groeit, of uit meerdere functies gaat bestaan zoals testers, project- en releasemanagers. Zelfs als we de impact van een context switch negeren blijven de andere argumenten staan: geen documentatie, gebrek aan prioritisering, nadelen betreft onderhoud, etcetera.

Ik werk aan een project met meer dan 20 miljoen lijnen code verspreid over talloze subprojecten samen met honderden andere software engineers. Als ik ergens een foutje in de weergave van een menu tegenkom dan is korte bug met een screenshot véél duidelijker en waardevoller dan een willekeurige patch waarin ik het zelf op probeer te lossen.

[Tarkin]

downtime schreef op dinsdag 5 december 2017 @ 22:40:
[...]

Eerlijk gezegd, als software (source code) zomaar zonder testen en documentatie wordt aangekocht, zonder input van mensen die er wel verstand van hebben, dan heb je als bedrijf wel grotere problemen dan de vraag hoe je met bugs omgaat. Dan zou ik op zoek gaan naar een werkgever die over 5 jaar niet failliet is door wanbeleid.

Overheid, gotta love it maar kan zelden failliet gaan

Er zijn hier inderdaad wel meer problemen maar in ons eigen kleine hoekje roeien we met de riemen die we hebben.

Peter schreef op dinsdag 5 december 2017 @ 22:59:
Degelijk ontworpen software heeft verschillende componenten. Dat kunnen volledig losse systemen zijn, maar ook onderscheid van functionaliteit tussen verschillende bestanden of zelfs functies in hetzelfde bestand creëert dat effect.

Als ik een foutje in de weergave van een menu tegenkom terwijl ik bezig ben met een routine om data te importeren dan is de context switch tussen de twee soorten code duurder dan het summier opschrijven van het probleem.

In grotere projecten zullen zulke disciplines vaak door verschillende personen ingevuld worden—specialisatie. In dat geval ben ik mogelijk niet eens op de hoogte van het menu component, de afwegingen in het ontwerp, de veranderingen die nog in aanbouw zijn of hoe het getest wordt (regressietesten!). Misschien moet het halve menu opnieuw geschreven worden om de fout juist op te lossen.

Stel dat ik het probleem toch oplos, en hier zélf een fout in maak. Dan zit je al met een situatie waarin het niet meer triviaal is om uit te zoeken waar het mis gegaan is. Een tester stelt vast dat er nog steeds een probleem is op het moment dat mijn verandering teruggedraaid wordt.

Tenslotte zegt een probleem in het menu helemaal niets over de kwaliteit van mijn routines.

Dit soort problemen worden alleen maar groter zodra het team groeit, of uit meerdere functies gaat bestaan zoals testers, project- en releasemanagers. Zelfs als we de impact van een context switch negeren blijven de andere argumenten staan: geen documentatie, gebrek aan prioritisering, nadelen betreft onderhoud, etcetera.

Ik werk aan een project met meer dan 20 miljoen lijnen code verspreid over talloze subprojecten samen met honderden andere software engineers. Als ik ergens een foutje in de weergave van een menu tegenkom dan is korte bug met een screenshot véél duidelijker en waardevoller dan een willekeurige patch waarin ik het zelf op probeer te lossen.

Akkoord, maar in principe haal je dat een beetje onderuit met het "you build it, you maintain it" principe. Waar je maar met 1 team een applicatie (of deel van bij heel grote applicaties) onderhoudt. Dan is het in principe het team die altijd op de hoogte is van aankomende veranderingen. Maar ook hier blijft de communicatie key denk ik.

[ Voor 65% gewijzigd door Tarkin op 06-12-2017 13:05 ]

[NMe]

downtime schreef op dinsdag 5 december 2017 @ 22:40:
[...]

Eerlijk gezegd, als software (source code) zomaar zonder testen en documentatie wordt aangekocht, zonder input van mensen die er wel verstand van hebben, dan heb je als bedrijf wel grotere problemen dan de vraag hoe je met bugs omgaat. Dan zou ik op zoek gaan naar een werkgever die over 5 jaar niet failliet is door wanbeleid.

Dat is wel heel erg ongenuanceerd. Ook legacy-code die gemaakt is door iemand die niet meer te bereiken is kan best onder een supportcontract ondergebracht worden bij een nieuw bedrijf. Dat nieuwe bedrijf zal dan ongetwijfeld de code analyseren, inschatten wat de problemen en risico's zijn, en op basis daarvan een realistisch prijskaartje plakken op dat supportcontract.

Wij hebben hier recentelijk ook zo'n product overgenomen binnen een realistisch kader: we ondersteunen eerst de oude software tegen uurtarief en starten binnenkort aan de vervanging voor die software. Lijkt me geen enkel probleem. En zelfs als die geplande vervanging er niet zou zijn is "tegen uurtarief" niet iets dat snel fout kan gaan.

[Hydra]

Tarkin schreef op dinsdag 5 december 2017 @ 22:30:
Wat doe je met een legacy product dat aangekocht is? Natuurlijk testloos en ongedocumenteerd (en nee, je mag het aankoop team niet benaderen met cactussen).

Dat zou betekenen dat ik de komende X jaren alleen maar code testbaar zit te maken. Geef mijn portie maar aan fikkie.

Ik snap dat het een hypothetische vraag is, en ik kan wel een hypothetisch antwoord geven. Maar de realiteit is gewoon dat ik vind dat 't leven te kort is om aan dat soort codebases te werken. Stress is een belangrijke factor in je leven en voor mij is stress in software engineering een balancing act tussen energie die je krijgt (leuke goed onderhoudbare shit bouwen) en energie uitgaven. Werken aan een dergelijk systeem 'kost' me alleen maar energie zonder dat 't me iets oplevert.

Misschien niet helemaal 't antwoord dat je gehoopt had maar dat is hoe ik er in sta.

NMe schreef op woensdag 6 december 2017 @ 13:08:
Dat is wel heel erg ongenuanceerd. Ook legacy-code die gemaakt is door iemand die niet meer te bereiken is kan best onder een supportcontract ondergebracht worden bij een nieuw bedrijf. Dat nieuwe bedrijf zal dan ongetwijfeld de code analyseren, inschatten wat de problemen en risico's zijn, en op basis daarvan een realistisch prijskaartje plakken op dat supportcontract.

Dit is vanuit het bedrijf geredeneerd, niet vanuit de persoon die het werk moet doen. Er is niks mis met legacy code; daar had hij het niet over. Hij had het gewoon over slechte code. Of die codebase nu 2 of 20 jaar bestaat is dan niet heel belangrijk

Wij hebben hier recentelijk ook zo'n product overgenomen binnen een realistisch kader: we ondersteunen eerst de oude software tegen uurtarief en starten binnenkort aan de vervanging voor die software. Lijkt me geen enkel probleem. En zelfs als die geplande vervanging er niet zou zijn is "tegen uurtarief" niet iets dat snel fout kan gaan.

Nogmaals; dat is puur vanuit je bedrijf geredeneerd. Als je als bedrijf doodleuk zo'n project aanneemt voor een uurtarief van 500 euro per uur is dat leuke en aardig, maar als dan van de 20 senior devs er na een maand nog maar 2 over zijn, dan is het toch echt een domme fout.

[ Voor 41% gewijzigd door Hydra op 06-12-2017 14:22 ]

[NMe]

Hydra schreef op woensdag 6 december 2017 @ 14:19:
Dit is vanuit het bedrijf geredeneerd, niet vanuit de persoon die het werk moet doen. Er is niks mis met legacy code; daar had hij het niet over. Hij had het gewoon over slechte code. Of die codebase nu 2 of 20 jaar bestaat is dan niet heel belangrijk

Lees z'n post nog eens, die was ook vanuit het bedrijf geredeneerd: het aankopen van legacy code zou zo slecht zijn dat je bedrijf eraan failliet gaat.

Nogmaals; dat is puur vanuit je bedrijf geredeneerd. Als je als bedrijf doodleuk zo'n project aanneemt voor een uurtarief van 500 euro per uur is dat leuke en aardig, maar als dan van de 20 senior devs er na een maand nog maar 2 over zijn, dan is het toch echt een domme fout.

Dat is altijd een risico maar dat is er ook eentje dat meegecalculeerd zou moeten worden in die risico-analyse voordat je het project aanneemt. Specifiek het voorbeeld dat ik noemde is mijn verantwoordelijkheid geworden en hoewel ik niet echt plezier heb als ik aan dat project werk zijn de verwachtingen aan alle kanten goed gemanaged en is eigenlijk iedereen tevreden.

Wat ik bedoelde te zeggen is in elk geval dat het niet per definitie slecht is om legacy code over te nemen, mits het bedrijf goed weet om te gaan met de mitsen en maren.

[Hydra]

NMe schreef op woensdag 6 december 2017 @ 14:27:
Wat ik bedoelde te zeggen is in elk geval dat het niet per definitie slecht is om legacy code over te nemen, mits het bedrijf goed weet om te gaan met de mitsen en maren.

Nogmaals; het gaat niet over legacy code. Legacy code is gewoon code die al een tijd draait. Dit ging over slechte code: waar uberhaupt geen tests of documentatie voor zijn. Dat kan prima iets zijn dat vanuit India over de muur gegooid wordt.

Da's echt wat anders. En daar vind ik dus dat je als bedrijf primair bij je senior developers te rade moet gaan of dat uberhaupt een goed idee is. En dat bedoel ik dus met dat je puur vanuit het bedrijf redeneert; dit gaat niet om uurtarieven, het gaat om of je als bedrijf een dergelijk risico wil nemen. Het afdekken in een uurtarief is te simpel gedacht.

[NMe]

Hydra schreef op woensdag 6 december 2017 @ 15:17:
[...]

Nogmaals; het gaat niet over legacy code. Legacy code is gewoon code die al een tijd draait. Dit ging over slechte code: waar uberhaupt geen tests of documentatie voor zijn. Dat kan prima iets zijn dat vanuit India over de muur gegooid wordt.

Da's echt wat anders. En daar vind ik dus dat je als bedrijf primair bij je senior developers te rade moet gaan of dat uberhaupt een goed idee is. En dat bedoel ik dus met dat je puur vanuit het bedrijf redeneert; dit gaat niet om uurtarieven, het gaat om of je als bedrijf een dergelijk risico wil nemen.

Dat zei ik ook. Ik denk dat we allebei hetzelfde bedoelen maar ik heb vandaag mijn dag niet zo dus misschien krijg ik het niet goed onder woorden gebracht.

[Tarkin]

Hydra schreef op woensdag 6 december 2017 @ 14:19:
[...]


Dat zou betekenen dat ik de komende X jaren alleen maar code testbaar zit te maken. Geef mijn portie maar aan fikkie.

Ik snap dat het een hypothetische vraag is, en ik kan wel een hypothetisch antwoord geven. Maar de realiteit is gewoon dat ik vind dat 't leven te kort is om aan dat soort codebases te werken. Stress is een belangrijke factor in je leven en voor mij is stress in software engineering een balancing act tussen energie die je krijgt (leuke goed onderhoudbare shit bouwen) en energie uitgaven. Werken aan een dergelijk systeem 'kost' me alleen maar energie zonder dat 't me iets oplevert.

Misschien niet helemaal 't antwoord dat je gehoopt had maar dat is hoe ik er in sta.

Was het maar waar, het is hier realiteit. Feit is wel dat ik ondertussen niet meer codeer en dat ik er niet zo "heel" veel last van heb, ik ben nu meer bezig met Scrummaster + Agile verder uitbouwen binnen de organisatie. Maar het is er wel. Mocht ik dagelijks aan die codebase moeten werken, zou het ook niet lang duren eer ik met m'n voeten zou stemmen.

Gotta love government

[Hydra]

NMe schreef op woensdag 6 december 2017 @ 15:20:
Dat zei ik ook. Ik denk dat we allebei hetzelfde bedoelen maar ik heb vandaag mijn dag niet zo dus misschien krijg ik het niet goed onder woorden gebracht.

Aww! Heb oprecht met je te doen. Ken dat soort dagen

Tarkin schreef op woensdag 6 december 2017 @ 15:48:
Was het maar waar, het is hier realiteit. Feit is wel dat ik ondertussen niet meer codeer en dat ik er niet zo "heel" veel last van heb, ik ben nu meer bezig met Scrummaster + Agile verder uitbouwen binnen de organisatie. Maar het is er wel. Mocht ik dagelijks aan die codebase moeten werken, zou het ook niet lang duren eer ik met m'n voeten zou stemmen.

Wil je dat wel? Ik heb een tijdje meer een 'management' richting gehad maar ik ben daar op den duur op terug gekomen en daar ben ik blij van. Te veel "agile coaches" en te weinig mensen die echt inhoud toevoegen. Ga liever de concurrentie aan op de inhoud i.p.v. wie 't hards roept hoe Agile moet.

P.s. heb echt een hekel aan de term 'coderen'.

[TommyboyNL]

NMe schreef op dinsdag 5 december 2017 @ 17:47:
[mbr]Ik heb net weer even twee reacties verwijderd (en nog even getwijfeld over de reactie hier direct boven). Nou ben ik het ook niet met Croga eens maar zullen we hem eens niet op de persoon aanvallen maar gewoon ouderwets op zijn argumenten?[/]

Prima als we hier alleen netjes mogen discussieren, maar roep dan ook @Croga tot de orde.
Verder lijkt het mij wel degelijk relevant om zijn achtergrond hier te noemen, om zijn geraaskal in perspectief te plaatsen.

[NMe]

TommyboyNL schreef op woensdag 6 december 2017 @ 20:59:
[...]

Prima als we hier alleen netjes mogen discussieren, maar roep dan ook @Croga tot de orde.

Ik heb Croga niet zien graven in jouw historie en werkervaring om vervolgens al jouw argumenten af te doen als onzin op basis van die achtergrond en verder niks zoals in die twee verwijderde reacties gebeurde.

Verder lijkt het mij wel degelijk relevant om zijn achtergrond hier te noemen, om zijn geraaskal in perspectief te plaatsen.

Dat is dan ook de reden dat ik die post boven de mijne liet staan.

[ Voor 5% gewijzigd door NMe op 06-12-2017 21:01 ]

[FreakNL]

Niemand heeft het nog gespot volgens mij maar de TS hangt Lean aan. Ik ben geen fan van die methode...

[BugBoy]

Croga schreef op vrijdag 1 december 2017 @ 13:02:
[modbreak]Dit topic is afgesplitst van Broncode Basisregistratie Personen openbaar.[/]
Nee. Dubbel Nee! TRIPPEL NEE!

Wat doe je met known issues? Ga je die verstoppen in een excel sheet? Ga je die wegvrotten in Jira? Nee, DIE LOS JE OP!

Bugs los je op, maar er bestaat ook iets als prioriteiten. Een bug die weinig impact heeft kan even wachten. Resources zijn niet eindeloos. En wat doe jij als je tijdens het oplossen van een bug een andere bug vindt? Dan laat je alles vallen en los je die bug op. Wel lekker recursief

Soms heeft een bug een beperkte impact, maar heeft het oplossen van die bug wel flinke impact die lastig is te testen. Vooral threading issues, locking issues, ... hebben een flink testtraject nodig. Als je dan meteen een bug fixt en je introduceert een ander (groter) probleem, dan word je klant echt niet blij van jou.

Maar ook al vind je dat het meteen moet. Je wilt bugs tracken in je bugtracker om te weten wat een tester moet testen. Ook wil je vaak bijhouden wat er mis is gegaan en wat de oplossing is. Soms vind je de oplossing op StackOverflow en dan is een linkje ook wel handig. Kan ook in de code.

Om eerlijk te zijn vind ik dat je een nogal hobbymatige insteek hebt. Wellicht ben je ook hobbyist en dan is dat prima, maar ik zou geen mensen op mijn projecten willen hebben met jouw werkwijze.

[TommyboyNL]

Laatste weerwoord, dan ben je van me af
NMe schreef op woensdag 6 december 2017 @ 21:01:
Ik heb Croga niet zien graven in jouw historie en werkervaring om vervolgens al jouw argumenten af te doen als onzin op basis van die achtergrond en verder niks zoals in die twee verwijderde reacties gebeurde.
[/quote]
Dat had hij best mogen doen, en dan had hij ook meteen gezien dat ik wél code geschreven hem in ruil voor euro's (en waarbij mijn baas besliste of het pletten van GUI bugs relevanter was dan essentiële functionaliteit toevoegen).
Verder kan je mijn bezigheden amper als graven bestempelen; zijn Linkedin profielnaam is identiek aan het domein in zijn t.net profiel

[Gaius]

BugBoy schreef op woensdag 6 december 2017 @ 21:08:
[...]
Maar ook al vind je dat het meteen moet. Je wilt bugs tracken in je bugtracker om te weten wat een tester moet testen.

Testers? Als de ontwikkelaars hun werk goed doen en een beetje opletten heb je geen testers nodig. Aldus een projectmanager waar ik voor gewerkt heb. Ik moest weer aan hem denken door deze discussie. Dezelfde wereldvreemde insteek die alleen toepasbaar is voor hobbyprojectjes zonder enige vorm van complexiteit.

[Harrie_]

Gaius schreef op donderdag 7 december 2017 @ 08:23:
[...]


Testers? Als de ontwikkelaars hun werk goed doen en een beetje opletten heb je geen testers nodig. Aldus een projectmanager waar ik voor gewerkt heb. Ik moest weer aan hem denken door deze discussie. Dezelfde wereldvreemde insteek die alleen toepasbaar is voor hobbyprojectjes zonder enige vorm van complexiteit.

Precies dit dus. Het vreemde van deze discussie vind ik nog dat er kennelijk mensen in dit topic zijn die differentiatie niet kunnen maken tussen:

• Een project van 2 weken waar 2 á 3 devs aan werken en waarbij (kleine) bugs dus on-the-fly kunnen worden opgelost.
• Projecten van jaren waar tig devs aan werken, waar over de jaren heen ook nogal wat personeelsverschuiving heeft plaatsgevonden en waar dus bugs optreden die niet direct te herleiden zijn.

[drm]

Jongens, is het probleem niet gewoon dat jullie allemaal op moeten houden met bugs te produceren? Dan hoeven we 't er helemaal niet over te hebben. Ik ben daar al jaaaaren mee opgehouden.

[itons]

Leuk topic

Het is al een paar keer genoemd, maar zonder inzicht in elkaars context is deze discussie eigenlijk niet te voeren. Kwaliteit is nu eenmaal een moeilijk te vangen concept EN in elke context anders (e-commerce vs. medisch/luchtvaart bv.).

Toch kan een "zero bug policy" ook in grotere complexe projecten werken, kijk bv. naar Spotify (slide 12-17) of zie onderstaande quote van Atlassian.

Facilitating
The team needs to be communicating well, and holding each other to high-quality standards. You make this happen by defining the quality bar, by organising testing sessions, and by ensuring that developers have the right tools, right data, and environments they need to carry out their testing efficiently.

How to practice

Set up blitz testing sessions, where you ask the developers to find problems with a specific feature. Make it fun, make it competitive, work with the developers to get them thinking like an experienced tester would. Get everyone involved in the conversations about whether bugs are worth fixing or not, and the reasoning behind it. Make it clear that you aren't a perfectionist requiring that every trivial issue is a must-fix, and come to a team agreement on which classes of bugs are not even worth raising.

Uit eigen ervaring weet ik dat het lastig kan zijn in legacy systemen, maar in "green field" situaties hebben de teams waar ik in heb gezeten altijd kunnen profiteren van een vergelijkbare aanpak. Direct bespreken met een developer en laten fixen OF zelf fixen indien triviaal. Recent voorbeeld van een productieincident waarbij een van de nieuwere services een concurrency issue liet zien, 8u issue bekend geraakt, asap gefixed op productie en dezelfde ochtend nog de fix uitgerold. Zonder tussenkomst van PO of andere stakeholders, maar op initiatief van het team. Oorzaak besproken, iedereen wat geleerd en verder. Dit is iets wat ik vooral zie gebeuren in teams met een groot gevoel van eigenaarschap en trots op wat ze bouwen.

Findings op legacy systemen gaan vaak wel de bugtracker in, om daarna de hele malle molen van prioritering e.d. in te gaan. Onlangs tijdens een productie incident waarbij de manager na 4 uur triage vroeg: "Kunnen we dan echt niets zien in de logging?" moest het team van de legacy app toegeven dat ze zoveel logden en dat er zoveel errors waren (van bekende bugs) dat het zoeken was naar een speld in een hooiberg. Bugtracker erbij gepakt en zo 3 unfixed issues gevonden die ik 1,5-2 jaar geleden gelogged had en medeverantwoordelijk waren voor de vervuiling in de logs.

TL;DR: Ik snap @Croga wel

[Creepy]

Je snapt Croga wel maar die bugtracker was blijkbaar toch wel handig

[itons]

Creepy schreef op zondag 10 december 2017 @ 15:57:
Je snapt Croga wel maar die bugtracker was blijkbaar toch wel handig

Als je dat uit het voorbeeld haalt

[downtime]

Creepy schreef op zondag 10 december 2017 @ 15:57:
Je snapt Croga wel maar die bugtracker was blijkbaar toch wel handig

Juist niet. Als die unfixed issues niet gelogd maar meteen opgelost waren dan was het probleem nu niet geëscaleerd

[Creepy]

Je vergeet dat bugs waarvan besloten word om ze niet te fixen ook niet worden vastgelegd. Nu kon je ze dus nog terugvinden. Anders was daar opnieuw onderzoek voor nodig geweest.

Dat niet vastleggen werkt dus 2 kanten op

[ Voor 12% gewijzigd door Creepy op 10-12-2017 16:54 ]

[Tarkin]

drm schreef op zondag 10 december 2017 @ 14:08:
Jongens, is het probleem niet gewoon dat jullie allemaal op moeten houden met bugs te produceren? Dan hoeven we 't er helemaal niet over te hebben. Ik ben daar al jaaaaren mee opgehouden.

Heb ooit zo'n manager gehad die met z'n droge ogen vroeg om gewoon geen bugs meer te schrijven. Dan was het probleem opgelost (catch, hij meende het echt ook, na 2h discussieren hebben we het maar opgegegeven)

[bwerg]

Ik vraag me af wat er dan gebeurt als er een bug binnen komt die het beste door een aantal personen opgelost kan worden, die net op team-uitje zijn, of 3 weken op zomervakantie? Bug onthouden, of mailen? Hoe voorkom je dat je mailbox een ad-hoc bugtracker wordt waarbij je vlaggetjes gaat gebruiken om de status bij te houden?

[Onbekend]

Tarkin schreef op zondag 10 december 2017 @ 19:17:
[...]


Heb ooit zo'n manager gehad die met z'n droge ogen vroeg om gewoon geen bugs meer te schrijven. Dan was het probleem opgelost (catch, hij meende het echt ook, na 2h discussieren hebben we het maar opgegegeven)

Je kreeg daarna veel meer ontwikkeltijd en testtijd toebedeeld?

[Alain]

Wij registreren bugs alleen als het meerdere projecten aangaat. De algemene software is dusdanig veel gebruikt (en weinig geüpdatet) dat er eigenlijk geen bugs meer boven komen drijven. Bij ons bestaat klantspecifieke software alleen binnen een paar projecten. Meestal maar één.

Een bugfix wordt in een rapport geregistreerd, met de projecten erbij waar het invloed op heeft. Puur mensenwerk.

Ik zeg niet dat dit de juiste manier is, maar gezien lage hoeveelheid producten en de weinige bugs na oplevering hebben we niet echt een registratiesysteem nodig. Dit kan door elkaar te informeren.

[Radiant]

bwerg schreef op zondag 10 december 2017 @ 20:19:
Ik vraag me af wat er dan gebeurt als er een bug binnen komt die het beste door een aantal personen opgelost kan worden, die net op team-uitje zijn, of 3 weken op zomervakantie? Bug onthouden, of mailen? Hoe voorkom je dat je mailbox een ad-hoc bugtracker wordt waarbij je vlaggetjes gaat gebruiken om de status bij te houden?

Die komen dan maar terug

[Haan]

Tarkin schreef op zondag 10 december 2017 @ 19:17:
[...]


Heb ooit zo'n manager gehad die met z'n droge ogen vroeg om gewoon geen bugs meer te schrijven. Dan was het probleem opgelost (catch, hij meende het echt ook, na 2h discussieren hebben we het maar opgegegeven)

Ha zo'n project heb ik ook een keer meegemaakt, de project manager liet op magische wijze de hoeveelheid bugs afnemen.. Kijkend naar de lijst: 'not a bug, not a bug, not a bug', etc. Project op een haar na volledig gefaald omdat er met een product live gegaan zou worden dat aan alle kanten rammelde.

[Swedish Clown]

Harrie_ schreef op donderdag 7 december 2017 @ 09:54:
[...]


Precies dit dus. Het vreemde van deze discussie vind ik nog dat er kennelijk mensen in dit topic zijn die differentiatie niet kunnen maken tussen:

• Een project van 2 weken waar 2 á 3 devs aan werken en waarbij (kleine) bugs dus on-the-fly kunnen worden opgelost.
• Projecten van jaren waar tig devs aan werken, waar over de jaren heen ook nogal wat personeelsverschuiving heeft plaatsgevonden en waar dus bugs optreden die niet direct te herleiden zijn.

Dit dus.

In het project waar ik op zit, hebben in de afgelopen 12 jaar, +-250 developers gewerkt (op 1 repo) met +-75.000 commits op de main repo (submodules voor het gemak even achterwege gelaten). Als ik de iets meer dan 100 submodules mee reken, kan je het aantal commits makkelijk vertienvoudigen schat ik zo

Even los van het feit dat wij een wettelijke verplichting hebben om elke change gedocumenteerd te hebben in JIRA (of vergelijkbaars) zou het zonder bug reports één grote puinzooi worden.

Er zijn verschillende categorieën bugs en elke bug kent z'n eigen prioriteit.

Zijn er bugs die NU opgelost moeten worden, zal de On Call persoon van het desbetreffende team gebeld worden. Ook dan zal de bug gedocumenteerd moeten worden maar is het prima als de ticket in JIRA summier is. Dat kan later verder ingevuld worden, de prio ligt op dat moment op het fixen van de bug.

Gaat het om een bug waar de impact lager is, zal afhankelijk van de prioriteit bepaald worden of die bug vandaag, morgen, deze week, deze maand of later opgelost worden. Een bug kan prima een edge-of-an-edge case zijn en een dermate lage prio krijgen dat die (praktisch) nooit gefixed wordt. Dergelijke bugs worden over het algemeen gesloten als "won't fix". Voor het nageslacht is het wel zo handig als die bug netjes gedocumenteerd is zodat mocht die vaker optreden, duidelijk is waar de bug is ontstaan en wat (toendertijd) als mogelijke oplossing aangedragen was.

[incaz]

itons schreef op zondag 10 december 2017 @ 15:08:

Toch kan een "zero bug policy" ook in grotere complexe projecten werken, kijk bv. naar Spotify (slide 12-17) of zie onderstaande quote van Atlassian.

Ik lees daar eigenlijk geen zero-bug policy in? "Get everyone involved in the conversations about whether bugs are worth fixing or not, and the reasoning behind it."

Het lijkt me ook vrij nutteloos om dit ongeregistreerd te doen - want als je dan samen hebt besloten dat een bepaalde bug niet de moeite van het fixen waard is, en de volgende keer wordt de bug weer gevonden, en dan krijg je die discussie opnieuw?

[Hydra]

itons schreef op zondag 10 december 2017 @ 16:01:
Als je dat uit het voorbeeld haalt

Wat hadden we er volgens jou dan wel uit moeten halen? Dat kritieke bugs zo snel mogelijk opgelost moeten worden bestrijdt niemand namelijk.

[Mercatres]

Wij tracken alle bugs die we tegenkomen. Eerst controleren we de backlog of het geen duplicate is, en anders maken we het aan in Jira. Die worden dan geflagged en dan door de PO opgepikt en geëvalueerd. Als het kritisch genoeg is, komt dat ticket meteen in de sprint, en anders komt ie in de volgende sprint of zelfs in de backlog.
Om te voorkomen dat die backlog gaat uitpuilen van de bugs waar niemand iets van weet doen we het volgende:
- Regelmatig backlog grooming sessies (1x per week), o.a. story points geven, maar ook uitleggen wat de bug is: context scheppen.
- Elke developer gaat zelf regelmatig door de backlog heen, en geeft commentaar + bekijkt de reproduceerbaarheid. Als het ticket niet meer relevant is, wordt deze automatisch geclosed.

Dit ziet er uiteraard uit als gigantische overhead, maar het zorgt er wel voor de we (het team bestaat uit 7 man) op z'n minst een notie hebben van wat er nog in zit. Dit heeft ook als bijkomend voordeel dat als we ooit in de buurt van de bug komen, we kijken of we hem mee kunnen fixen. Of nog beter, als hij door een refactoring van een ander ticket helemaal irrelevant is geworden.

We doen dit enerzijds omdat we merken dat het in het voordeel van de developers is om een notie te hebben van de tickets (omdat we zo een klein team zijn, gaat dit). Anderzijds verplicht ons QA-systeem dat ook, i.v.m. traceability.

[Tarkin]

Mercatres schreef op dinsdag 12 december 2017 @ 13:31:

- Regelmatig backlog grooming sessies (1x per week), o.a. story points geven, maar ook uitleggen wat de bug is: context scheppen.
- Elke developer gaat zelf regelmatig door de backlog heen, en geeft commentaar + bekijkt de reproduceerbaarheid. Als het ticket niet meer relevant is, wordt deze automatisch geclosed.

Ziet eruit als een goed systeem. Toch 1 opmerking. Van het moment dat je story points kan geven aan een bug, betekent dat dat dit duidelijk is wat er misgaat. M.a.w. het kan ingeplanned worden als een story. Dan veranderen wij het ook in een story en wordt het zo geschat door de PO's.

dus

Incident >> Bug >> Story
>> Quick fix

Incident als er gebruikers geblokkeerd zijn/ het systeem in brand staat/andere shit waarvoor je uit je bed gebeld kan worden
Bug: It's annoying maar de gebruikers moeten er maar mee leren leven/ er is een workaround/ we weten nog niet wat er moet gebeuren
Story: Het wordt ooit wel eens opgepakt naarmate de hoogste business value/prioriteit/aan wie de PO het eerst beloofd heeft.

[Mercatres]

Tarkin schreef op dinsdag 12 december 2017 @ 17:40:
[...]


Ziet eruit als een goed systeem. Toch 1 opmerking. Van het moment dat je story points kan geven aan een bug, betekent dat dat dit duidelijk is wat er misgaat. M.a.w. het kan ingeplanned worden als een story. Dan veranderen wij het ook in een story en wordt het zo geschat door de PO's.

dus

Incident >> Bug >> Story
>> Quick fix

Incident als er gebruikers geblokkeerd zijn/ het systeem in brand staat/andere shit waarvoor je uit je bed gebeld kan worden
Bug: It's annoying maar de gebruikers moeten er maar mee leren leven/ er is een workaround/ we weten nog niet wat er moet gebeuren
Story: Het wordt ooit wel eens opgepakt naarmate de hoogste business value/prioriteit/aan wie de PO het eerst beloofd heeft.

Klopt helemaal, m'n verhaal was niet geheel correct. Bugs krijgen inderdaad geen Story Points, om de simpele reden dat we die niet verdienen - we hadden het al eerder goed moet maken.

[Kwistnix]

Ik snap wel enigszins waar de drang vandaan komt om constateringen over imperfecties in de broncode direct op te pakken - afgezien van het feit dat dit absoluut niet altijd realistisch is. Even daargelaten of het dan bugs betreft of kandidaten voor refactoring of wat dies meer zij. Bij mijn huidige klant draait een behoorlijk aantal webapplicaties (~20) die bijna zonder uitzondering al jaren meegaan. De backlog die daar bij hoort staat vol met allerlei issues die niet zelden ook jaren onaangeraakt zijn gebleven. Dat is niet voor alle issues een "probleem", maar een behoorlijk aantal is al wel door de realiteit ingehaald, niet meer relevant of zo slecht beschreven dat je er niks meer mee kan. Die situatie is onwenselijk en het maakt een backlog onoverzichtelijk en onwerkbaar.
Nu zijn wij actief bezig met alle issues door te nemen en te beoordelen of we er nog iets mee willen/kunnen. Best wel een klus en het voelt een beetje als vechten tegen de bierkaai.

[Tarkin]

Kwistnix schreef op woensdag 13 december 2017 @ 12:22:
Ik snap wel enigszins waar de drang vandaan komt om constateringen over imperfecties in de broncode direct op te pakken - afgezien van het feit dat dit absoluut niet altijd realistisch is. Even daargelaten of het dan bugs betreft of kandidaten voor refactoring of wat dies meer zij. Bij mijn huidige klant draait een behoorlijk aantal webapplicaties (~20) die bijna zonder uitzondering al jaren meegaan. De backlog die daar bij hoort staat vol met allerlei issues die niet zelden ook jaren onaangeraakt zijn gebleven. Dat is niet voor alle issues een "probleem", maar een behoorlijk aantal is al wel door de realiteit ingehaald, niet meer relevant of zo slecht beschreven dat je er niks meer mee kan. Die situatie is onwenselijk en het maakt een backlog onoverzichtelijk en onwerkbaar.
Nu zijn wij actief bezig met alle issues door te nemen en te beoordelen of we er nog iets mee willen/kunnen. Best wel een klus en het voelt een beetje als vechten tegen de bierkaai.

Die issues moet je gewoon closen en horen niet in je bugs backlog

[Kwistnix]

Dat lijkt mij evident en dat is dus ook precies waar wij nu mee bezig zijn. Voordat je bij dat moment bent - waarop je kan oordelen dat het niet meer relevant is/kan zijn - gaat er echter wel tijd voorbij, soms behoorlijk wat tijd, en blijft de backlog maar groeien. Je hebt echt afspraken en discipline nodig om een backlog werkbaar te houden en als die er een tijd lang niet geweest is, dan erf je een monster.