Softwareontwikkelaars: hoe vertel je je baas / klant dat een softwarefout verantwoordelijk is voor het feit dat je jouw deel van het project niet hebt voltooid?

nvoigt

2015-09-25 11:32:17 UTC

view on stackexchange narkive permalink

Tenzij je zonder twijfel hebt bewezen dat de fout in je compilergereedschapsketen zit, moet je aannemen dat het jouw fout is. Ofwel bij het coderen of bij het gebruik van de tools van uw toolchain.

Als het een bug in uw toolchain is, moet u deze melden, online hulp en tijdelijke oplossingen zoeken en een eromheen. Analyseer de situatie en presenteer een lijst met mogelijke oplossingen die beter zijn dan wat uw gebruiker nu ervaart. Misschien kunt u een versie hebben zonder concurrency. Dat is misschien beter dan er een te hebben die willekeurig crasht. Rapporteer al deze opties aan uw leidinggevende en meld ook dat u nog niet weet wanneer het oorspronkelijke probleem zal worden verholpen.
De kans is groot dat u niet kunt bewijzen dat het een fout in uw tool is ketting. Dus je zoekt nog steeds. Vertel uw leidinggevende dat u nog steeds bezig bent met debuggen. Vraag hem of er een deadline is waarop het misschien beter is om te stoppen met wat je doet en over te schakelen naar een alternatief plan. Maak een lijst van alle opties zoals hierboven.

Over het algemeen geldt: hoe hoger uw rapport, hoe minder geïnteresseerde mensen in de details zijn. Uw tools zijn uw tools. U bent verantwoordelijk voor het kiezen van de tools waarmee u uw werk kunt doen. Het falen van uw tools wordt gezien als uw falen. Dat lijkt misschien oneerlijk, maar probeer het vanuit een ander perspectief te zien: stel dat u een vakman inhuurt en hij vertelt u dat hij vrijdag klaar is met de reparatie. Aanstaande vrijdag vertelt hij je dat hij zijn werk niet kon afmaken omdat een van zijn werktuigen kapot ging. Zou je dat kunnen schelen of accepteren als excuus? Zijn tools zijn zijn verantwoordelijkheid, toch?

Dus zolang uw rapport naar technische mensen gaat, vermeld dan het probleem met de tools en presenteer alternatieve oplossingen. Als het hoger gaat, geef de tools dan niet de schuld. Dat wordt alleen als excuus gezien. Presenteer gewoon alternatieve oplossingen.

Gereedschap gaat kapot. En we hebben geen back-ups (of back-ups van back-ups in geval van dubbele storing) voor elke afzonderlijke tool. Dus in werkelijkheid, als dit gebeurt, vertelt de vakman de waarheid en is er een gesprek over wanneer de tool beschikbaar kan zijn, welke andere benaderingen kunnen worden gevolgd, enz. Een arme vakman zou het gesprek kunnen vermijden, het oppervlakkig opknappen, de deadline halen en ga verder en laat waardeloos werk achter je.

@MichaelDurrant Dat is hetzelfde met softwareontwikkelaars. Vertel je klant dat je het niet op tijd hebt gehaald en presenteer alternatieve oplossingen. Maar haal niet alleen je schouders op, wijs naar het gereedschap en geef het de schuld. Dat zal niet werken.

Of doe wat Microsoft doet: voeg een lijst met "bekende problemen" toe naast de documentatie van de software die u verkoopt ...

"U bent verantwoordelijk voor het kiezen van de gereedschappen waarmee u uw werk kunt doen." Dat is niet altijd waar; veel ontwikkelaars bevinden zich in een situatie waarin de vrijheid om hun eigen tools te kiezen expliciet van hen wordt afgenomen. Ondanks dat feit vermoed ik dat "het falen van uw tools wordt gezien als uw mislukking", hoogstwaarschijnlijk waar is, * vooral * in situaties waarin de ontwikkelaar niet de vrijheid krijgt om zijn tools te kiezen.

@MichaelDurrant Misschien een arme vakman, maar een goede zakenman. Ik ben lang genoeg in softwareontwikkeling geweest om te weten dat de twee vaak hetzelfde zijn.

+1 voor "Tenzij u zonder twijfel heeft bewezen dat de fout in uw compilergereedschapsketen zit, moet u aannemen dat het uw fout is".

'Stel dat je een vakman inhuurt en hij vertelt je dat hij vrijdag klaar is met de reparatie.' Ik denk dat dat een nogal slecht passende analogie is voor de meeste softwareontwikkelingswinkels. Vaak is het meer als "stel dat je een vakman inhuurt en jij, die over het algemeen weinig tot geen kennis van het vak hebt, vertel hem dat hij vrijdag klaar zal zijn en vraag / luister niet naar zijn mening over wat een realistisch tijdsbestek zou zijn ". Zul je aanstaande vrijdag redelijk zijn en accepteren dat je een onrealistische deadline stelt, of geef je de vakman gewoon de schuld dat hij niet aan je willekeurige schema voldoet?

Ten eerste kan ik niet genoeg benadrukken (maar het is hetzelfde antwoord als dit). HET IS JOUW FOUT. Als ontwikkelaar is het jouw taak om je te ontwikkelen. Er is geen enkele taak die u kunt teruggrijpen naar uw tools. Als uw gereedschap een bug bevat, werk er dan omheen of vervang ze. Het enige acceptabele antwoord (voor mij) zou zijn "Ik kan X doen, met Y in plaats van Z, maar het zal wat langer duren." Als je hamer breekt, krijg je een nieuwe hamer. Als die breekt, neem je een grotere hamer. Als die kapot gaat, neem dan een kraan. Als dat niet werkt, probeer dan explosieven. Maar als ontwikkelaar kan ik je vertellen dat niemand om je tools geeft behalve jij

En als het zich in uw gereedschapsketen bevindt, identificeert u wat bugs zijn en doet u er iets aan of vermijdt u de buggy-functie. Het is mij drie keer overkomen, nadat ik het gebruik van de afgeluisterde functie had vermeden, heb ik tweemaal de beledigende delen van de runtime-bibliotheek herschreven, een keer inclusief het uitvoeren van een in-memory patch van de afgeluisterde routine omdat het origineel onaangeroerd moest blijven.

semi-relevante xckd: http://xkcd.com/1579/

"Kom je vrijdag, ga je redelijk zijn en accepteer je dat je een onrealistische deadline stelt, of geef je de vakman gewoon de schuld omdat hij niet aan je willekeurige schema voldoet?" Als je een manager bent, geef je de vakman natuurlijk de schuld ... .

@coteyr kun je bijvoorbeeld niet zomaar _iOS_ of _Android_ vervangen, die beide bugs hebben.Ik heb gisteren net een grote `swiftc`-bug getroffen, die pas in de volgende release van Xcode zal worden opgelost.Gelukkig kunnen compiler-bugs worden omzeild, framework-bugs ... niet noodzakelijk.

Hanky Panky

2015-09-25 12:54:39 UTC

view on stackexchange narkive permalink

You've tried every solution in your book (debugger, Google, forums, etc.) and still haven't been able to solve it.

No you haven't. You haven't talked to any of your senior team members. You haven't taken any help from your team lead. You haven't considered the fact that if you can not reproduce the bug someone with more experience can reproduce it and assist you in debugging it.

So

Software developers: How do you tell your boss/client that a software bug is responsible for your failure to complete your part of the project?

Just don't. That is just not a real excuse. If a software bug is responsible then discuss that with your employer. You can't tell them I could not upload a 1 GB file quickly because office dial-ups are slow. Instead you should tell them to get you the connection speed you need to get your job done, and then do just that. Get the job done :)

If a team member comes to me and tells me there is this bug that I just can't seem to resolve and it is hard to reproduce I'd be more than willing to help them or at least give them time on it. On the other hand, if they come to me that, no, that can't be resolved because this and this tool is messing it up, I'd really consider it a lame excuse.

It's fine if we can't solve everything on our own, but it's not fine if we don't ask for the team's or a senior's help and just downplay the bug. Dedication to resolving an issue is more important than perfection. Many a times what we consider beyond any explanation is a piece of cake for others.

Uw oorspronkelijke antwoord merkte alleen op dat de veronderstelling van het OP dat hij alles had geprobeerd verkeerd was en niet eens vermeldde hoe hij vanaf hier moest gaan of hoe hij het bij het management moest bespreken, wat zijn eigenlijke vraag was. Je bewerking geeft daar nu een goed antwoord op. Wat het niet aardige deel betreft, verwees ik alleen naar uw zeer korte afwijzing van het punt van het OP, dat soms als onbeschoftheid kan worden geïnterpreteerd. Het is een goed punt om te maken, maar vooral op deze site wil je voorzichtig zijn met hoe je dingen verwoordt om te voorkomen dat mensen te defensief reageren. (Oh, en +1).

Steve Jessop

2015-09-25 16:39:56 UTC

view on stackexchange narkive permalink

You tell your boss,

I am trying to solve a problem, and I can't, try as I might. I've tried every approach I can think of (debugger, Google, forums, etc.) and still haven't been able to solve it. Perhaps the bug randomly disappears on each run and there's no possibility of the bug being related to my use of concurrency techniques. I conclude, then, that the bug only manifests under certain runtime conditions which I am unable to reproduce or isolate.

That is to say: tell your boss the truth. Personally I don't think anyone should spend more than a day stuck on something without talking to other people in their team (either boss or peers) and giving them the opportunity to provide a useful insight or suggestion. Ideally much less time than that, and I think some people would set a much smaller hard limit (indeed one principle of pair programming is that you should spend zero time stuck on something on your own, ever).

Of this, "there's no possibility of the bug being related to my use of concurrency techniques" is a bold claim, of which the boss (or a more senior tech assigned to deal with this problem that you can't deal with) may require substantial proof. Therefore it's worth assembling this proof in advance, because you've quite possibly reached the conclusion as a result of several disparate investigations. You don't want it to come across as either "I have a hunch that it's not concurrency", or "I have rejected out of hand the possibility it's my use of concurrency, because I am so excellent that I never make mistakes". Other than the boldness of this claim, I don't think anything in what you say is particularly out of the ordinary or should give cause for concern.

Your boss is then responsible for assigning additional time from people better able to understand or fix the problem. As others have said, the extra person doesn't even necessarily need to be any better than you, simply a fresh look can help. Your boss or the team might also decide that since the issue is intermittent, what's needed is more precise logging (or other instrumentation) on a wider variety of environments and data, in the hope of catching the bug occurring more times than you'd be able to alone with your dev environment. Worst case, if the bug lies not in your company's code but in some dependency, you need to prove that and you need to give the third party the best possible chance of reproducing it so that they can fix it and provide an update.

If you don't have a boss then a client would be different. The details of what you've tried are no use to them. If you're self-employed contracting for a client, and you have no boss, and you can't complete the project you've contracted for, then in most cases you can't just ask them to help you fix the problem. You need to tell them there's a delay. But you're going to have to fix or work around the problem yourself, or find someone else who can.

+1 voor 'Uw baas of het team kan ook besluiten dat, aangezien het probleem zich met tussenpozen voordoet, nauwkeuriger logboekregistratie (of andere instrumenten) nodig is voor een grotere verscheidenheid aan omgevingen en gegevens, in de hoop de bug vaker dan je zou alleen kunnen zijn met je ontwikkelomgeving. " Stuur een geïnstrumenteerde build naar de klant. (Hoewel dit geen antwoord is op de vraag 'hoe vertel je de baas', is het een zeer geldige volgende stap.)

Er zijn inderdaad managers, dus u kunt ze de echte dope geven en zij kunnen beslissen hoe ze het aan belanghebbenden presenteren. Zet uw baas niet op één hoop in de categorie van belanghebbenden - hij is er om u te helpen, niet om u te achtervolgen. Als hij er is om je te achtervolgen, heb je waarschijnlijk een andere manager nodig.

Gezien het feit dat het onmogelijk is om te bewijzen dat een programma vrij is van fouten (met uitzondering van het hebben van een volledige specificatie en het kunnen verifiëren van het programma ertegen, wat niemand kan voor software die groot genoeg is) is al dit gepraat over bewijs nogal misleidend.

@Voo: nou, ik bedoel een argument dat iemand overtuigt van de waarheid van zijn stelling. Het zal geen bewijs zijn in de formele wiskundige zin. Dus als je jezelf er niet toe kunt zetten om het bewijs te noemen, dan moet je ervoor zorgen dat je alles in orde hebt, de informatie en inhoudingen zijn die de beweerde onmogelijkheid ondersteunen dat het je eigen schuld is dat je vergeet iets te vergrendelen dat je had moeten vergrendelen ;-)

Mathematics

2015-09-25 16:50:09 UTC

view on stackexchange narkive permalink

Quite simple - tell them:

It's a random bug which is really hard to reproduce, and I spend x time on it. Now,

Do you want me to spend further time on trying to reproduce it, which may take x amount of time or you just don't know at all how long will it take?
Work on something more important and come back to it in future (in case more information becomes available).

Stay honest, and don't push yourself too much; it's not YOUR fault. I used to have same feelings as you, but now I keep it simple. The worst that can happen is they will fire you, and maybe then you find a better job... Stay positive.

To be a happy developer, you MUST need to be fearless.

Of zoek een manier om er omheen te werken.

@keshlam hij noemde in kwestie dat de bug erg moeilijk te reproduceren is, ik neem aan dat hij weet van het domein waarin hij werkt, en heeft het opgegeven nadat hij alles heeft geprobeerd wat hij kon .. hem vertellen een manier te vinden om rond te werken is recursief

ook je punt komt aan bod in mijn 2e opsommingsteken, blijf zoeken tot je een oplossing of iets nieuws vindt :)

Niet noodzakelijk. Het hangt er soms van af hoe nauw hij gefocust is op het laten werken van een bepaalde oplossing. Ben daar geweest, heb dat vaak gedaan.

gnasher729

2015-09-25 13:24:21 UTC

view on stackexchange narkive permalink

Eerste regel: als er een bug is, komt dat doordat je iets verkeerd doet. De vraag is: wat doe je verkeerd? Als je jezelf ervan overtuigt dat het probleem ergens anders ligt, ga je het probleem niet vinden.

Tweede regel: leg het probleem uit aan een andere softwareontwikkelaar. Het zal je verbazen hoe vaak het simpele feit dat je het probleem uitlegt je geest zal concentreren en dat je zelf de oplossing vindt. Het is vrij typerend tussen ervaren ontwikkelaars dat men een probleem begint uit te leggen en halverwege het proces stopt omdat ze de oplossing hebben gevonden.

Derde regel: leg het probleem uit aan een andere softwareontwikkelaar. Waar je de onbewuste beperking hebt dat je je eigen bugs niet wilt vinden omdat het betekent dat je toegeeft dat je een fout hebt gemaakt, heeft de andere ontwikkelaar dat probleem niet en kan hij vaak gemakkelijk een probleem vinden die je hebt gemist. (Betekent niet dat je dom bent - het werkt in beide richtingen).

Vierde regel: als er geen andere ontwikkelaar in de buurt is, gebruik dan een kartonnen programmeur. Gewoon een kartonnen uitsnede van een persoon, en je legt het probleem uit aan die kartonnen programmeur. Zie je, in het tweede geval heeft de andere ontwikkelaar eigenlijk niets gedaan om je te helpen, ze moesten er gewoon zijn. Dus je kunt het probleem net zo goed uitleggen aan de kartonnen programmeur.

Dichtbij. Je vraagt niet om een kartonnen uitsnede. Je vraagt het aan de eend. De eend is wijs en alwetend. http://blog.codinghorror.com/rubber-duck-problem-solving/

Nooit in mijn leven een eend gevraagd. Het was altijd de kartonnen programmeur. Vooral als er een programmeur is - je kunt niet zeggen "let op als ik je als mijn rubberen eendje gebruik", maar je kunt wel zeggen "let op als ik je als kartonnen programmeur gebruik".

Langs deze lijnen heb ik ontdekt dat het maken van een Stack Overflow-bericht veel helpt. Ik zei niet dat ik het had gepost, ik heb het gewoon gemaakt. Als u uzelf dwingt de vraag uit te typen, leidt dit vaak tot het antwoord. Je kunt op zijn minst beginnen met antwoorden voordat ze het doen - je ziet het alsof het het probleem van iemand anders was. Ik heb 83 SO-vragen gepost in de afgelopen 5+ jaar, maar ik heb er waarschijnlijk meer dan 500 geschreven.

De rubberen eend-aanpak is geweldig. Toen ik begon, legde ik mijn baas de hele tijd problemen uit (hij was een professionele bugfixer voor een manager). De helft van de tijd, voordat ik klaar was met het uitleggen van het probleem, zou ik een eenvoudige oplossing bedenken. De andere helft gaf hij advies dat me ertoe bracht het op te lossen.

"Als er een fout is, komt dat doordat u iets verkeerd doet." Dit is _de meeste tijd_ waar. Het is zeker niet de hele tijd waar. Bugs in besturingssystemen, bibliotheken, ketens van compilertools en zelfs de hardware zelf (inclusief de processor!) Kunnen en zullen bestaan. Ook is de documentatie voor de bovenstaande dingen soms niet correct. In geen van deze gevallen heb je per se echt iets verkeerds gedaan.

@reirab: 95% van de tijd verhindert de aanname dat de bug zich ergens anders bevindt, u deze niet te vinden.

@gnasher729 Ja, ik zou zeker niet adviseren om aan te nemen dat de bug niet in je code zit en, zoals ik al eerder zei, meestal wel. Ik wees er net op dat het niet juist is om te zeggen dat een bug zeker betekent dat je iets verkeerd doet.

@corsiKa: Misschien heb ik door slaapgewoonten het probleem uitgetypt en kon ik nog steeds geen oplossing bedenken.

pjc50

2015-09-25 20:19:41 UTC

view on stackexchange narkive permalink

de bug manifesteert zich alleen onder bepaalde runtime-omstandigheden die je niet kunt reproduceren of isoleren

.. tot dusver.

Escaleer en vraag om hulp . Alle bugs kunnen uiteindelijk worden getraceerd via een reeks van "op dit punt heb ik X terwijl ik Y zou moeten hebben. Waar komt X vandaan?", Het kan gewoon tijdrovend zijn. Vooral als het nog steeds gebeurt. Eenmalige rare gebeurtenissen laten misschien niet genoeg bewijs achter, maar als er een bug aan de gang is, dan heb je er meer omheen nodig om je te vertellen wat er gebeurt.

Ik heb precies 3 toolchain-bugs gehad in 20 jaar (Quartus codegeneratie; GCC-coredump op bepaalde C ++; MSVC2008 gestructureerde uitzonderingsafhandeling op ARM). Ze zijn vrij zeldzaam, en in elk geval vond ik een testcase bewijst dat er een probleem was in de tool in plaats van alleen te beweren dat het er moest zijn omdat ik geen bug in mijn code kon vinden .

paparazzo

2015-09-25 17:15:58 UTC

view on stackexchange narkive permalink

Those are the hardest bugs. When you get towards the end reproducing the bug is often harder than fixing it. Sometimes what you think is environmental is really just a sequence of events that you have not yet identified. Developers will test for how they expect the program to be used and users will do stuff you never expected. Sometimes it is bug that only comes out at production load.

I don't know your environment but do you have a global exception handler that reports the bug details and call stack? That is what we do. Let the user see the ugly error so they can tell you about it. "Sorry you got an error. Please report the following to technical support so the we may address the problem." If the app is connected to a database write the error to the database. Did you write the software up front to deal with and report bugs / exceptions?

I have a serialization error right now that happens only about 1 in 400 runs (and I am not getting a call stack). I am pretty sure it is the framework and not my program but I cannot prove it and it is still my problem. Luckily can just restart the program. It is a known bug that we are tying to fix but decided to release with that bug.

Boss versus client is different.

Boss:Describe the bug and the impact. Are only certain features impacted or is the program as a whole impacted. At this time I am not able to reproduce the bug. Until I can reproduce the bug I cannot fix it. At this point I suspect the bug is environmental. What have you done so far. What do you plan to do. Do you need help. Don't tell your boss you are sure there's no possibility of the bug being related to your use of concurrency techniques unless you can prove it.

Client:
Currently we (say we to the client so feel like a team is working on it) have a known bug. The impact is X. It is a priority bug and we are actively working on it but at this time we don't have a fix date.

Don't go into can't reproduce with the client unless you need their help to reproduce.

If it is the client that reported the bug then you can go into more detail.

Iets wat ik onlangs heb geleerd: unit testing. Als ik een bug niet kan vinden, kan ik unit-testing gewoon gebruiken om het programma brute kracht te geven om me de exacte output / het exacte gedrag te geven dat de bug finder heeft gerapporteerd.

OK, werkte het?

jwenting

2015-09-27 17:45:46 UTC

view on stackexchange narkive permalink

I've dealt with this a few times. MOST of the time it IS your bug, and you can and should fix it.
Even if it's not, most of the time you can and should be able to work around the problem by rewriting a small portion of your code.
The very few times that seems impossible, someone else on the team might be able to do it (especially if you're one of the more junior members of the team).

In the exceedingly rare case that 1) the problem is NOT caused by your code being faulty AND 2) you can provide verifiable evidence that this is the case AND 3) you can't rewrite your code to work around the problem, then it's time to inform your managers that what they want can't be done without switching toolsets, libraries, whatever is at fault and that that's going to be a major investment, maybe it's better to drop the requirement that exposed the problem until another solution can be found.

But in 20 years in the industry, and years before as a student and hobbyist, I've only encountered that I think twice.
That's not to say I've never run into bugs in compilers, libraries, or tools. But in decades I've only once or twice encountered one where we couldn't work around the bug without an investment that would be higher than the cost of switching to another tool(set).

Admit that you're stumped, ask others to take a look as well (and do so early), and provide what documentation and research you've already done to those people so they don't have to do it all over again.
That's your responsibility as a team member.

user42391

2015-09-25 17:06:42 UTC

view on stackexchange narkive permalink

A bug is an obstacle. It does not sound like "that's just the way it is" is an option, so the bug needs to be dealt with.

If you don't see yourself making progress on the bug, and if you cannot think of anything else to do, you need to figure out the next option to get a hold on the bug. That might mean external expertise, but more likely internal expertise.

As a "senior software developer", I semi-regularly (namely about once a year or so) have to track down a really bad bug where the final verdict boils down to "code generation error". Which then requires isolating the bug into a reasonably independent example and contacting the compiler writers. Depending on your compiler, this might require some non-cheap support program membership, just to be allowed to report a bug with software you paid for (of course you could also chat up a developer in a bar and slip her a USB drive as long as her management isn't watching: developers rarely see the point of not knowing about bugs).

If you are running out of tools and/or wits, you either need to acquire new tools or wits, or you need to focus on a workaround making the bug not show up for whatever reason.

As an employee, it is your duty to spend company resources, including but not limited to your own work hours, in a responsible manner with a reasonable expectation of return value.

ManirajSS

2015-09-26 00:25:47 UTC

view on stackexchange narkive permalink

that the bug only manifests under certain runtime conditions which you are unable to reproduce or isolate.

Usually system will behave in a systematic way.When we fail to understand the system everything seems to us random.Yes it'll really hurt if we can't fix/reproduce the bug.Usually not all the bugs need code fix. even simple configuration change can fix the bug.

So We can't approach the randomly reproducible bug in a random way.We have to follow systematic way to corner that random bug.

Note down what are all the scenarios/methods you have followed to reproduce/fix that bug.Ask yourself what else you have missed out or not yet tried out and try them also.If everything fails ask your peers/seniors for help.

What do you tell the person to whom you are to report?

Show your Efforts.

As a software developer you cant simply say i can't fix this bug.

Since you have approached this bug in a systematic way you can show your efforts to your boss.

If you covered 9 out of 10 possible methods somebody else can suggest you that how to try that 10th method. (if you approached in systematic way and documented all cases.)

So you saved your time and also other's time who is looking into this bug to fix the bug or at least it will help to straight away get in to the point to find the root cause of the bug.

Lynob

2016-10-19 19:01:01 UTC

view on stackexchange narkive permalink

Als het gerelateerd is aan de IDE, is de kans groot dat het geen bug is die nooit kan worden opgelost. Of zoek een alternatief
Als het gerelateerd is aan de programmeertaal, dan hetzelfde als hierboven, of je zou het gewoon aan je supervisor kunnen vertellen en hij zou het begrijpen omdat hij de taal en zijn beperkingen kent. JS is bijvoorbeeld JS, je moet de gebreken kennen voordat je ermee gaat werken.
Als het gerelateerd is aan een bibliotheek die je gebruikt, als het een open source-bibliotheek is, ga dan meestal met de maker praten ze zijn bereid om te helpen, als ze niet proberen te vorken of een vork of een alternatief te vinden. Als het een gesloten bron is, zoek dan een alternatief. Alle bibliotheken kunnen in het algemeen worden vervangen, met uitzondering van enkele, zoals een hardwarebibliotheek die alleen door de fabrikant wordt onderhouden.
Als het om een software gaat die u gebruikt, verander dan de software, bijvoorbeeld JDBC-stuurprogramma wordt gepubliceerd onder GPL en we hadden een GNU-licentie nodig en konden geen ander stuurprogramma vinden, we zijn begonnen over te schakelen naar Postgeres, zelfs als het tientallen jaren zal duren, er is geen excuus, als er alternatieve software is, moet je die gebruiken en je redenen melden
Als de bug verband houdt met een API-beperking van een derde partij, dan is er niets dat je kunt doen, je vraagt op stackoverflow om hulp, als ze je niet kunnen helpen, vertel het dan aan je klant. Een klant vroeg me ooit om afbeeldingen op te halen van een openbare Instagram-hashtag, ik vroeg op SO. Toen ik er eenmaal zeker van was dat Instagram het niet toestaat, stuurde ik hem een e-mail en gaf ik hem een link naar mijn vraag met een screenshot van de Instagram-website, er kan niets aan worden gedaan, maar bewijs het aan je klant.
Als het gerelateerd is aan een bug die ik niet heb genoemd, die zo belangrijk en zo moeilijk op te lossen is, en geen enkele collega kan je helpen, vraag dan op SO, de kans is groot dat je zoveel upvotes krijgt en als stackoverflow niet kan worden opgelost het, kunt u uw vraag gebruiken om uw bewering te ondersteunen dat deze bug onoplosbaar is.