[HN Gopher] Nobody ever gets credit for fixing problems that nev...
___________________________________________________________________
Nobody ever gets credit for fixing problems that never happened
(2001) [pdf]
Author : Jtsummers
Score : 197 points
Date : 2024-02-22 20:26 UTC (2 hours ago)
(HTM) web link (web.mit.edu)
(TXT) w3m dump (web.mit.edu)
| Jtsummers wrote:
| Only previous submission that had a discussion (and it's worth
| reading through):
|
| https://news.ycombinator.com/item?id=8940820 - Jan 24, 2015 (50
| comments)
| ghaff wrote:
| In about that same timeframe, Y2K is also really good example.
| Nothing of note really happened. But if people had just ignored
| it a lot of things probably would have.
| rhcom2 wrote:
| Another example is ozone depletion.
| ender341341 wrote:
| yeah, I've had that discussion
|
| "we were all worried about the ozone and nothing happened,
| this is just a repeat and people will stop talking about it
| any time now"
|
| and my response is "'Nothing' happened because the
| governments acted fast and turned it around so now it's
| mostly just boring stuff like catching some factoryy that
| decides to go cheap and use banned chemicals to save a buck"
| gumby wrote:
| This is a very important case. There was an enormous investment
| in fixing Y2K, starting long before the day in question (e.g.
| financial instruments with expiration dates after Y2K had to be
| fixed before they became due), so on the day there was only a
| smattering of minor residual bugs.
|
| There were a few jokes about it in the newspapers but by and
| large the public just ignored it.
|
| I work on climate and hope / hoped that the same would happen,
| but it's looking like it will soon get everybody's attention
| regardless.
| throwup238 wrote:
| _> I work on climate and hope / hoped that the same would
| happen, but it's looking like it will soon get everybody's
| attention regardless._
|
| Unfortunately those fixes are slated for Humanity 2.0, _Homo
| extinctus_.
| mcdonje wrote:
| Y2K would negatively impact companies' bottom lines if not
| dealt with, directly, in a short and known timeline, in
| predictable ways.
|
| Climate change will impact companies in different ways at
| different times. Oil companies, for instance, are
| incentivized to ramp up production as much as possible while
| also diversifying.
|
| The way to get all companies to take appropriate actions is
| to not allow them to externalize costs. That means a
| significant carbon tax.
| konfusinomicon wrote:
| I'm sure I'm not the only one that can't wait for the 2038
| problem to get closer. bank accounts gonna be jumping like a
| 3-peat Micheal Jordan when those consultation fee checks
| start rolling in.. provided the Boston Dynamics dogs haven't
| taken over yet
| jcadam wrote:
| Java EE will be the COBOL of 2037...
| nsxwolf wrote:
| The mitigations were done so well today the public remembers
| Y2K as a "scam".
| ghaff wrote:
| I suspect most people don't even remember a 25-year ago
| non-event as anything.
| UniverseHacker wrote:
| What, what do you mean nothing happened? I'm in my underground
| bunker, do you think it would be safe to come out and look
| around?
|
| You guys are all in your Y2K underground bunkers still, right?
| captainbland wrote:
| Yeah, it's the year 24, don't worry about it. A human is
| probably still able to type this.
| Smoosh wrote:
| My advice looking back over the past 25 years . . . stay in
| the bunker.
| ghaff wrote:
| I didn't worry. Even took a trip to a different country.
| Though I can totally understand why some people (know you're
| joking) might have played it more conservatively.
| HankB99 wrote:
| Yeah. I've heard folk who should know better (looking at you,
| John C. Dvorak) call Y2K a nothingburger and suggest the effort
| to prevent problems was a total boondoggle.
|
| Disclaimer: I was part of that effort. The funny thing was that
| I was brought back to a previous client to fix something that
| my previous efforts had literally caused. Took me 20 minutes to
| fix it once I saw what the problem was. And then there was a
| "while you're here, can you take a look at this ..." That
| lasted about two years until they closed the department and
| moved it to NY, NY.
|
| At least I got credit in terms of billable hours.
| ghaff wrote:
| While I often enjoyed reading Dvorak columns in PCMag, he was
| always more someone who liked to provoke people than offer
| thoughtful commentary.
| Justsignedup wrote:
| the readiness paradox:
|
| If you are prepared, nothing interesting happens, life moves
| on, people opened a notebook and pressed a few buttons.
|
| If you are not prepared, the texas grid freezes, people die,
| people lose their savings, and "nobody could have imagined it
| would be this bad".
| nonrandomstring wrote:
| Recommend "Left of Bang"
|
| In strategic sysadmin and cybersecurity this is staple
| thinking, and a useful part of what I teach now.
|
| Problem for vigilant thinkers is the rewards, as explained in
| TFA, are perverse.
|
| People are content with technology to be magical. They don't
| see the millions of people quietly repairing it and planning
| to keep it all going smoothly.
|
| To "bosses" cybersecurity only bring them problems, and cost
| them money apparently doing nothing. The same for any defence
| force, until you need it.
|
| Did some nice interviews for international sysadmin day last
| summer [1].
|
| [0] https://www.goodreads.com/book/show/22663095-left-of-bang
|
| [1] https://cybershow.uk/episodes.php?id=15
| aksss wrote:
| Not "probably". I was involved at ground level fixing code for
| BP in '98. Can say without a doubt that bad things would have
| happened. And not because my salary depended on it - there was
| no shortage of opportunities to work on other things,
| obviously. It was legitimately an issue that would have
| crippled the energy industry (major players, and all their
| many, many dependents). I infer from this experience that the
| impact would have been the same on many other industries (e.g.
| finance, resource development) directly and indirectly.
|
| But it is a great example. I still run into people who recall
| Y2K as an example of much ado about nothing. No, no!! It wasn't
| an issue for you because many people worked hard to prevent the
| problems.
|
| Those problems were not terribly complex just pervasive and
| critical, requiring a high LOE. It wasn't like a huge moon-
| landing engineering problem to be held up as some
| accomplishment of humanity, more akin fixing a lot of dumb
| Challenger o-ring problems before a blow-up.
| pintxo wrote:
| Or: The Preparedness paradox [1] / "There is no glory in
| prevention"
|
| [1] https://en.wikipedia.org/wiki/Preparedness_paradox
| NovemberWhiskey wrote:
| Another variation on the problem is the over-allocation of
| resources to preventing problems which actually happened once,
| versus those that are more severe but haven't happened yet.
|
| This is a management problem, because no-one wants to be
| accountable for a repeat incident even if it was rational to be
| working on something else more important.
| thfuran wrote:
| There's a ton of reactionary legislation on the books that
| exists pretty much entirely because politicians wanted to be
| seen doing something. It's mostly crap.
| NovemberWhiskey wrote:
| Yeah, the legendary politician's fallacy:
|
| 1) We must do something.
|
| 2) This is something.
|
| 3) Therefore, we must do this.
| wolverine876 wrote:
| I thought that was the voter's fallacy.
| shoo wrote:
| https://www.youtube.com/watch?v=vidzkYnaf6Y
| arp242 wrote:
| This is probably a bit too cynical; it's not just
| "politicians who want to be seen doing something"; the public
| often wants something done as well. And "we didn't do
| anything after that incident from ten years ago and now it
| happened again" is not a good look. Complex stories about
| trade-offs and the cure being worse than the disease often
| don't "play well" in the media, especially not with the
| opposition demanding that "something could have been done!"
| And corporations tend to be pathologically risk-averse.
|
| Politicians, the media, corporations, and the public all have
| a part in this.
| thfuran wrote:
| >the public often wants something done as well.
|
| Sure, that's why the politicians want to be seen doing it.
| But the legislative focus is often on getting something
| passed now while it's a hot issue rather than on eventually
| getting a good bill passed (let alone deciding that we
| actually already have the correct amount of legislation on
| the topic).
| solidsnack9000 wrote:
| A lot of gun legislation is like this. Whatever your view of
| guns is, there is no rationale for a "safe hand gun roster"
| like California's where the Glock 17 Gen 3 is on it, but the
| Gen 5 -- which introduces a basic safety improvement for
| left-handed people -- is not.
| brazzy wrote:
| The thing is: it's very easy to play up the likelihood and
| severity of problems that are entirely imaginary. This can be
| just a bad habit, but also a deliberate tactic. In either case,
| a lot of effort, time, money, etc. is wasted.
|
| Waiting for something to actually happen before allocating
| resources to preventing it is (to some degree) a rational
| policy.
| cpill wrote:
| yeah that to the Ai doomers who are making six figures off of
| it
| Vecr wrote:
| The argument there is that waiting for "it" to happen would
| be way too late. Especially if "it" is a billion people are
| dead and the rest of the people don't have much time.
| Pet_Ant wrote:
| > Another variation on the problem is the over-allocation of
| resources to preventing problems which actually happened once,
| versus those that are more severe but haven't happened yet.
|
| I've heard this called "institutional scarring" in a blog post
| somewhere. The idea is a small wound can be replaced with tough
| inflexible tissue. The jist of the blog post was that just
| because something happened, doesn't mean you have to change
| things to ensure it never happens again because that can be an
| over-reaction that really burdens your future. Accept that loss
| and that it just might happen again, but that may be better
| than onerously preventing it with certainty.
| thefatboy wrote:
| just aint true if you file a bug report
| nomel wrote:
| In our org, this was brought up. People who had problems, then
| fixed them, were the ones being seen and recognized by higher
| level management, and awarded for fixing the problems, when they,
| often, _shouldn 't_ have happened in the first place.
|
| Now we have something akin to a "person that prevents problems"
| award. It's a nice gesture, but, even though I received one, I
| think it's mostly nonsense. You don't get the face
| time/experience presenting with the higher level managers. It's
| almost impossible to prove that you prevented catastrophes, by
| working extra hours, or doing the right thing. Nobody likes a
| "Hey look, I told you so!" sort of perspective, no matter how
| it's framed.
|
| To me, this is the most gratification-limiting aspect of being a
| software engineer: time is required to test quality of
| foresight/design. Rewarding retroactively, for great past
| decisions, doesn't happen. There are systems I designed, when
| making a pittance for compensation, that's still being used a
| decade later, across multiple companies, almost entirely
| unmodified. That, _now objectively_ , good work wasn't seen or
| recognized by anyone paying me at the time, and can't be seen by
| anyone now. I burned good time for a "good job me!" as a reward.
| As I get older, that mental masturbation seems less desirable,
| since it's usually at the expense of the surprisingly limited
| life credits that we _spend_ on those tasks. But along with most
| other nerds, I can hardly stop myself because it 's an _innate_
| obsession.
| esafak wrote:
| This happens in organizations that don't measure and respect
| precursors or _leading indicators_ of success /failure --
| organizations that do not practice organizational observability,
| to coin a phrase. Which is to say, most of them, because this is
| not something one thinks of until one has suffered its absence.
| Your managers have to think like SREs, and be technically
| sophisticated enough to model and address this problem.
|
| Does anyone know any great management books on this subject?
| diatone wrote:
| This is a great insight, the idea that management has to look
| at leading indicators for the org itself. Makes me think that
| beyond line management, a manger's job is to behave as an
| investor and steward of the org, instead of getting involved in
| the details.
|
| Not a management book per se, but Working Backwards popularised
| an Amazon approach of thinking about the organisation in terms
| of mechanisms. You might find that useful.
|
| I've always wanted to dig into Scarlet Ink, Dave Anderson's
| blog, but never have, and I suspect it'll be quite useful for
| you too.
| hakunin wrote:
| I've been contemplating the issue in the headline, as pertains to
| my value. When I help somebody in 40 mins with something they've
| been stuck on for 3 months, my value is clear to everyone. When I
| work there the whole time, and nobody ever gets stuck for 3
| months, my value is unclear. Don't know how to deal with this
| paradox.
| runamuck wrote:
| Easy - half a$$ your code and when it breaks - swoop in, "fix
| things" (actually do it right) and play the role of hero! (I've
| seen so-called "Rock Stars" at places I worked do this over and
| over)
| syndicatedjelly wrote:
| Would you feel good about being that kind of engineer, if the
| external validation was great enough?
| circusfly wrote:
| It's OK, the new validation method is AI driven, we're
| good.
| sodapopcan wrote:
| When the external validation is monetary then you gotta do
| what you gotta do.
| tmtvl wrote:
| There are people with integrity and principles; and then
| there are people who _can_ pay their rent every month.
| SilasX wrote:
| Hah, that was in my archetypal description of the fake 10xer,
| that _somehow_ they are able to swoop in and fix their
| spaghetti code, come what may, while no one else can make
| sense of it:
|
| https://news.ycombinator.com/item?id=18462325
| Jtsummers wrote:
| Don't do it right, double down on the flaws. You had a 3k
| SLOC single function (all in main) C program to do something
| that could be expressed cleanly and clearly in 200 SLOC. Some
| specific sequence of inputs leads to an error. Instead of
| tidying it up, removing the repetition that led to the
| mistake, you copy/paste everything again and add another 100
| cases to your various switch/case statements (actually you
| use if/else because switch/case might make things clearer).
| The specific problem is solved, but in a year another buggy
| code path will be discovered and you'll have another chance
| to play hero. In 5 years it'll be 50k SLOC of C all in main,
| that could have been under 1k SLOC (still all in main). No
| one else will be able to fix it but you!
| actionfromafar wrote:
| For extra points, keep the sane solution in a secret source
| file, then implement a compiler which generates the
| obfuscated spaghetti. :-P
| farhanhubble wrote:
| This is exactly what happens at many software companies.
| People,sometimes under pressure to meet deadlines, apply
| totally crazy fixes to stop one problem and create new
| problems.
| sharess wrote:
| Another option is to work at a consultancy where you hop
| aboard a new customer project every 3-6 months. Approach
| every customer as an opportunity to do some resume-driven
| development and pick a bunch of untested new technologies to
| experiment with. Be sure to do at least a couple of
| presentations to tell everyone about the hottest new things
| you are doing to bring value to the customers. Leave the
| project once it slowly starts sinking and then just keep
| hopping from customer to customer. You will be far away once
| the sea water starts coming through the windows and the non-
| technical people directing these projects will never figure
| out what you did.
|
| I have seen that this is one of the most efficient ways to
| advance your career especially in larger consultancy
| companies with hundreds or thousands of different customers.
| ponector wrote:
| It is more easy: do your job right, but do not comment, fix
| or somehow improve work of your colleagues. Let them fail,
| aknowledge failure and only then come with fix, get all
| praise.
|
| Never point to the possible issues at the code reviews,
| retirement refinements etc.
| godelski wrote:
| I don't think you're wrong, but god what a waste of time.
| Can't we just fix the actual problem?
| Scoundreller wrote:
| don't even need to half a$$ it, just use timebombs.
|
| https://en.wikipedia.org/wiki/Time_bomb_(software)
|
| Usually only works if you're the only dev, unless you get
| creative with counters like the original devs that made some
| nice cash fixing it all for y2k
|
| (officially: don't do this)
| darth_avocado wrote:
| That's literally how promo packs work in FAANG (minus the N)
| and other adjacent tech companies.
| samstave wrote:
| For i in employment ensure there is someone who checks in
| with me every month when they read this line of code, else,
| stop code from running so they come to me.
| ortusdux wrote:
| See also: The Locksmith's Paradox -
| https://medium.com/@pk.patrick.kelly/the-locksmith-paradox-6...
| Pikamander2 wrote:
| "When you do things right, people won't be sure you've done
| anything at all."
| quickthrower2 wrote:
| There is a quote about the job being free but you are just
| paying for the 20 years experience.
|
| The opposite is the lemons market. It is why getting some
| wet building work done that is actually waterproof is a
| fucking dark art. Even the pros hiring pros get fucked
| because the "is waterproof" part is invisible.
| wolverine876 wrote:
| Life and its rewards aren't perfect. Work with honest,
| intelligent people; genuinely do your best; your days will be
| much better and the odds will be with you.
| bmacho wrote:
| > Don't know how to deal with this paradox.
|
| Think that it is the management's fault if they misjudge you.
| They have the chance to judge you correctly, yet they misjudge
| you. Their fault entirely.
| somethoughts wrote:
| One approach to showing value is as follows:
|
| 1.) Create a spreadsheet with all of the features of your
| group's/company's products(s) listed in rows.
|
| 2.) Create a column for every team member in the group and
| highlight the lead developers for each feature.
|
| 3.) Then ask each team member to add a checkmark in their
| column for every feature for which they would be willing to be
| on hook for 24x7 triage pager duty.
|
| Over the long term - the most valuable contributor(s) on the
| team will be the one(s) with the most checkmarks next to the
| features they led development on (i.e. they write
| understandable code and document well) combined with the most
| checkmarked rows in their column (i.e. they proactively seek to
| understand other peoples codebases).
| cutemonster wrote:
| Couldn't there then be a risk that now some people want to
| avoid higher risk projects, and just build the simpler
| features, and get more checkmarks
|
| What if the table in fact shows which people are best at
| dodging the hard work
|
| Combined with showing who has the most friends in the office
| (giving checkmarks to features built by one's friends)
| godelski wrote:
| > Couldn't there then be a risk that now some people want
| to avoid higher risk projects, and just build the simpler
| features, and get more checkmarks
|
| This is kinda a well known phenomena in medicine[0]. Same
| with lawyers. I'm just reminded of this scene from Silicon
| Valley[1]. It's messed up and why everyone needs to be very
| careful with metrics and remember that metrics are only
| guides, not targets.
|
| [0]
| https://www.theguardian.com/society/2016/jan/29/doctors-
| avoi...
|
| [1] https://www.youtube.com/watch?v=5sTbjO3eI_0
| FridgeSeal wrote:
| Kind of ignores the risk externalities have on projects no?
| If you tried your best to deliver something, but another
| teams priorities changed, or the business/market shifted, or
| the project got bogged down in planning/politics outside of
| that team members control, or if the team needs to integrate
| with a system (external or legacy) that's out of their
| control and is notoriously flaky and torpedoes their velocity
| and morale.
| hackerlight wrote:
| Really good bosses make up for this. They push teamwork and
| collaboration, but at the same time they know the details of
| what every individual is doing and how they each contribute to
| the whole, and they can ~accurately
| compensate/promote/terminate. This prevents demoralization of
| team members. Team members psychologically need to be
| recognized for their individual contribution.
|
| These bosses tend to be competent ICs who became team leads,
| they are best positioned to judge the ICs they manage because
| they themselves are masters at the craft.
| quickthrower2 wrote:
| Modern "agile" systems don't work well with you. They want you
| to deliver X points of features in 2 weeks. Sounds like you'd
| be better off as a consultant? But then you need to do all that
| biz dev stuff! Or find a great CTO to work for (or be the CTO)
| who understands. You only need one job.
| baxtr wrote:
| I think an underrated way to deal with this phenomenon is
| proper self-marketing. Talk endlessly what you have done to
| prevent catastrophe. Describe the avoided catastrophes vividly
| so that people get a clear picture.
| mcbishop wrote:
| Better yet, be in a work culture where people happily give
| credit to and praise others.
| nhumrich wrote:
| Sometimes you can't quantify actual avoided things. For
| example you can't prove that a regulation stove actually
| prevented what could have been a kitchen fire.
| mattgreenrocks wrote:
| Work for yourself. The fewer bugs you create, the faster you
| iterate. And the faster you iterate, the better your chances of
| finding product/market fit.
| atleastoptimal wrote:
| The solution is to be a shameless self-marketer of all the work
| you do.
| xyst wrote:
| Value is in the eye of the beholder is what I discover. Got to
| play the game.
|
| If you are an IC, you play it up with the right people. Those
| right people fight for you instead of the other way around.
| When the "we need to cut the fat" talks come around, suddenly
| you are not on the chopping block. But that also assumes the
| people fighting for you are not on the chopping block.
|
| Soft skills across the industry is highly under valued. Knowing
| when to pick a fight or hold your tongue is also important (ie,
| reading the room).
|
| I hate it but you got to do what you got to do to get that
| cheddar
| ajmurmann wrote:
| Or worse: People get stuck quite frequently and ask you for
| help pretty quickly. You get everyone unstuck, but your own
| work falls behind and when your boss's boss asks for metrics on
| developers you have few points delivered and few LOC changed.
| Your boss tries to explain, but your head is the one that rolls
| next when layoffs happen.
| welder wrote:
| Quit your job and work for yourself.
| bluGill wrote:
| I always get cynical when I see awards for software releases.
| Someone always gets an award for staying up late to fix a last
| minute problem. Normally the person that should have written good
| code in the first place so they wouldn't have had to come in
| late. The award should go to the person (likely people) who never
| got called in at all in the first place because we didn't find a
| bug in their code.
| coldtea wrote:
| Except TSA security theater. They see their budgets grow and seen
| as essential, for preventing problems that never happened.
|
| But in this case, if those problems were to happen, they wouldn't
| be stopped by their measures.
| seaourfreed wrote:
| The opposite. Department heads get fired for allowing blow-ups in
| their area, that should have been avoided. "Getting credit" means
| keeping the job managing the department via preventing problems.
| datadrivenangel wrote:
| This may be one of the biggest challenges facing human
| civilization. Climate Change, Financial Bubbles, etc.
| circusfly wrote:
| Volvo probably is an exception in the car world.
| crestfallen wrote:
| My memory is a bit hazy but it's a good story.
|
| At one place, there was some important order processing taking
| place. As is fairly typical, couldn't rely on getting all the
| required info. Or critically, getting all the required info
| _correctly_. Some extra data, slightly missing pieces but enough
| to work, etc. etc. Some could be pretty gross. We built
| validation to massage some inputs, modify processing, what have
| you to address as many of those as we could think of. The team
| put in some metrics to identify which validations were
| "triggered" for each order. Neat. If we'd add more, we'd add a
| date to it.
|
| It was great. We reported those stats so anyone could see
| anytime, but we'd also send out some comms about it every now and
| then. It also helped tremendously when a coworker or customer or
| whoever would say "Oh no! What happens if XYZ?" and we'd say no
| worries, we already addressed it, and we prevented #### orders
| from getting stuck for XYZ.
|
| It showed that the team was thoughtful, that we were invested in
| making this work, that work needed to _continue_ to keep things
| running smoothly, and we had data to back that up.
|
| Really helped switch the conversation in the org because folks
| could see it. If someone pointed out that we hadn't thought of
| something, it honestly was more about what do we do vs. why
| didn't we think of this. (Yes, there is a comment here about poor
| org thinking or blame culture, but some of that exists
| everywhere.) More proactive. Recognition of preventive quality.
| People gave us accolades and it bubbled up to some good and real
| recognition at higher levels too.
|
| I'm mangling the words here a bit but I hope you get the idea.
| nick_m wrote:
| Great article, and much of this resonates - but what template has
| been used here? It looks like it was created using LATEX.
| sudosteph wrote:
| Reminds me of a place I used to work. Every time they asked for
| feedback, my refrain was "nothing here gets prioritized without a
| PIR (post-incident response)". Towards the end of my time there,
| whenever a PIR-related ticket showed up, I would mark it as a
| duplicate of whatever actual ticket I had dying in the backlog
| that would have prevented it. It really hurt team morale to have
| no influence in preventing foreseeable issues in our domain area.
| Most of the rest of the team had even stopped suggesting
| improvements altogether because management refused to let us pull
| our own tickets in.
| acheron wrote:
| I don't get credit for my tiger-repelling rock even though we
| haven't seen any tigers.
| qorrect wrote:
| Are these magic rocks for sale?
| jgeada wrote:
| Reminds me of this cartoon (which I have posted on my office):
| https://naksecurity.medium.com/the-detriments-of-hero-cultur...
|
| This is why in many corporate cultures it pays not to proactively
| stop a problem that you know how to fix _if_ the problem is not
| in your immediate problem area. Let it be noticed, let it become
| someone else 's emergency, then fix it. Much better path to a
| reward that way. Of course, you should also be planning to leave
| said organization, in the long run it won't do well.
| reaperducer wrote:
| _Nobody ever gets credit for fixing problems that never happened
| (2001) [pdf]_
|
| I'm reminded of this every time I see some YouTuber or other
| social media click bait claiming that the Y2K bug was no big
| deal.
|
| The reason it was no big deal is because thousands of graybeards,
| like myself, stayed up many long nights for months ahead of time
| making sure things would work.
|
| I still remember the tension during the countdown to midnight
| UTC. Then the tension rising again during the countdown to
| Eastern time. Then once more at local time.
|
| Only when it was 2000 in Pacific did we unclench our cheeks.
| IshKebab wrote:
| I still don't quite buy that. Surely it's because computers
| mostly use epoch time for dates, not dd/mm/yy?
|
| Guess we'll find out in 2038.
| contact9879 wrote:
| Now they do at least
| xcv123 wrote:
| Many old programs written last century did not use epoch
| time.
|
| https://en.wikipedia.org/wiki/Year_2000_problem#On_1_January.
| ..
| woutersf wrote:
| I call these problems ticking time bombs. This way business has a
| catchy name to use for the thing they dont understand, its also
| very clear this needs to be looked at.
___________________________________________________________________
(page generated 2024-02-22 23:00 UTC)