ti 11. lokak. 2022 klo 12.23 Korbinian Bachl (korbinian.ba...@whiskyworld.de) kirjoitti:
> > > ----- Ursprüngliche Mail ----- > > > > If you are ok with a 80% failing page, I cannot help you, because in that > > case you can simply come up with another fallback which works 80%. You > know > > this leads/creeps to exponential growth of failures and work, yes? > > > > The right way to handle it is to inform the user that something has > failed, > > suggest the user to retry (or you can retry once programmatically if you > > think the problem is rare). > > > > And receive alerts from such problems in production and find the root > cause > > and fix it, for example by fixing a race condition issue by adding > blocking > > queues or whatever best suits your use case. > > Well, for me the thing is: if the whole page fails you need to fix it asap > - if only 10% of the page fails you could ignore it some time and have it > fixed at a later point in time when you have resources > free. > > I see this as a pure business administration problem: save money if > possible... I know this is not something a programmer likes but nobody of > us programms for free :) > It's same cost at the moment to program correctly as to program crap, but if you program crap, the costs accumulate in the future, from customer experience, trustworthiness, goodwill, support costs, rewriting the whole application after it has become spaghetti from technical debt, and so on. If you do not know all this, you will learn. If it is ok to have this error then maybe just ignore it, I just hope it's not a banking application ;) > > > > And from my experience I never expect my code to not have bugs in it, so > it > >> will fail at some point. I mean, why do we have so many regular wicket > >> releases if its bug free? ;) > >> > > > > Is not about being bug free, but how to respond to bugs and how to curb > > bugs and how to curb the impact of bugs. > > Right: have a way to ignore it a maximum amount of time till you fix it... > based on the impact of the bug itself. > In case the bug takes down everything you need to fix it asap. If it takes > down only a part: depending on the part itself you react... > Yes. Pick your battles, apply pareto principle, and so forth. Anyways, only you can find the solution (and timing) that best fits your application, as you know the business case and use case. ** Martin
