[HN Gopher] My fake job in Y2K preparedness
___________________________________________________________________
My fake job in Y2K preparedness
Author : bookofjoe
Score : 81 points
Date : 2024-08-31 16:23 UTC (6 hours ago)
(HTM) web link (www.nplusonemag.com)
(TXT) w3m dump (www.nplusonemag.com)
| mlyle wrote:
| > Finally, it was a fake job because the problem that the
| Conglomerate had hired Andersen to solve was not real,
|
| I don't really like the whole popular understanding of the y2k
| thing. _Substantial problems_ with infrastructure were fixed. It
| wouldn 't have been Mad Max, but business operations could have
| been affected for weeks. Instead, we had almost smooth sailing
| because there was an appropriate amount of preparation
| beforehand.
|
| (Not to say that there wasn't graft like he describes as part of
| that preparation).
| magicalhippo wrote:
| Back when I was just out of school, I worked as a computer tech
| guy. Our company got hired to test all the PC+BIOS version
| combinations a certain department had, to ensure they'd work
| after y2k.
|
| Spent several weekends rigging up computers, and running a
| battery of tests on them.
|
| Did actually find a handful of combos which misbehaved, mostly
| incorrectly handling the leap year IIRC. None of them had NTP
| running, so could have been an issue. A few didn't handle the
| transition well at all. Most got resolved by a BIOS update.
|
| I recall thinking after 2000 came and went that sure, a fair
| share of superfluous work had probably been done, but the
| reason it seemed like such a nothingburger afterwards was
| because a lot of work went into ensuring exactly that.
| dgfitz wrote:
| I read it as, a real problem wasn't identified by the
| management side of the company. Finding typos in spreadsheets
| and printing corrected versions to slap in a binder was a CYA
| event, the article says as much.
| RHSeeger wrote:
| > The problem was known variously as Y2K, ...
|
| I really hate this take some people have (especially people
| that weren't there at the time) that Y2K wasn't a real problem.
| It was a real, large problem effecting businesses across the
| globe. But the thing is, the problem wasn't that "everything
| was going to fail catastrophically at the turn of the year". It
| was that "some things could fail catastrophically at the turn
| of the year, and we didn't know which things would". So a lot
| of time and money went into figuring out which things actually
| had a problem, and fixing them. It was entirely possible that,
| if we didn't fix something, planes _could_ fall out of the air,
| or energy providers could shut down for long periods of time.
|
| So we spent lots of time and money finding out what things
| needed to be fixed. And "it turns out that not that not that
| many things did really need to be fixed" is a GREAT result from
| that time and money; arguably the best possible result. But it
| doesn't invalidate that the time and money was spent, in the
| same way that "I didn't get into an accident" doesn't
| invalidate the fact that wearing your seat belt is a good idea.
| cromulent wrote:
| It's infuriating.
|
| I worked on a Y2K project in 98-99 for a major car
| manufacturer. They tested the ERP system for Y2K (in 1997) and
| it failed, in a way that would make the business fail. They
| replaced it via this project and the business continued to be
| successful without interruption.
|
| Another company I know of simply backdated their whole system
| by 10 years. This worked, but unfortunately the contract cycle
| renegotation reminders then did not appear, and competitors
| took many of their contracts over the next year or so. They
| went out of business in a couple of years.
|
| I implemented a new manufacturing and retail system in 1992,
| and we used 4 digit years. The company owner complained that
| they were a needless expense and annoyance and that there was
| plenty of time to deal with Y2K. They continued to use the
| system well into the 2000s.
|
| The space shuttle never flew over New Year's eve/day as they
| couldn't handle a single year rollover, let alone a century.
| Some use cases can simply avoid the problem.
| kens wrote:
| Strangely enough, a few months ago I came across the bug fix
| for that Space Shuttle problem. "CR 93160: Year End Roll Over
| (YERO) Reset. Allows in-flight reset to January 1 without an
| IPL and complicated procedures while maintaining a good state
| vector."
|
| (IPL is "Initial Program Load", IBM-speak for a reboot.)
| RaftPeople wrote:
| > _It 's infuriating. I worked on a Y2K project in 98-99 for
| a major car manufacturer. They tested the ERP system for Y2K
| (in 1997) and it failed, in a way that would make the
| business fail. They replaced it via this project and the
| business continued to be successful without interruption._
|
| Same.
|
| I worked on multiple enterprise projects for Y2K where we
| advanced the dates on the customer's system and ran it so we
| could see the magnitude of the problems and prioritize the
| remediation process.
|
| There were some things that were temporarily annoying and
| there were some things that were critical to the business and
| could not be worked around manually by throwing people at it,
| the system needed to be fixed.
| zugi wrote:
| Perhaps this line from further down is what was meant by "not
| real":
|
| > The Andersen position was that "Y2K is a documentation
| problem, not a technology problem."
|
| Sure, there were other people at other companies solving the
| "real" Y2K problem, but the problem Andersen was solving was
| not so real.
| iwishiknewlisp wrote:
| *she
| rhdunn wrote:
| The Y2K problem would have manifested as the year 2000 being
| interpreted as 1900. As such, it could have affected anything
| around dates (age verification, paynment due dates, morgages,
| etc.). Other more extream issues (power outages) would have been
| unlikely but it is impossible to predict all the knock-on effects
| Y2K would have had.
|
| There were several issues that happened as a result of Y2K.
| voiceblue wrote:
| Maybe you are being downvoted because this is "obvious", but as
| it turns out it is not obvious enough for the TFA itself to not
| have this error: it prophesied that on
| January 1, 2000, computers the world over would be unable to
| process the thousandth-digit change from 19 to 20 as 1999
| rolled into 2000 and would crash
| ralferoo wrote:
| I came across a reasonable amount of perl code that happily
| formatted the year 2000 as 19100. The functions that
| converted from seconds-since-1970 to a "human readable" parts
| returned a year relative to 1900. Most people would format
| using sprintf("%d/%d/%d",$d,$m+1,$y+1900) but some code I
| inherited instead used sprintf("%d/%d/19%d",$d,$m+1,$y). I
| never did figure out if it was due to stupidity or malice.
| cristoperb wrote:
| See also David Graeber's "On the Phenomenon of Bullshit Jobs":
|
| https://strikemag.org/bullshit-jobs/
| rzimmerman wrote:
| I worked for about a year with a consulting firm that handled
| "Y2K compliance". Unlike this Andersen exercise in legal face-
| saving, it was a real job. Big companies hired us to do a full
| inventory of their site equipment (this included manufacturing
| plants, Pharma stuff) and go line by line with their vendors and
| figure out which components had known Y2K issues, which had not
| been tested at all, and which ones were fine/had simple fixes. We
| helped them replace and fix what needed to be fixed.
|
| Y2K was a real problem. The end-of-the-world blackouts + planes
| falling from the sky was sensationalism, but there were real
| issues and most of them got fixed. Not trying to take away from
| this very interesting story of corrupt cronyism, but there were
| serious people dealing with serious problems out there. "Remember
| Y2K? Nothing happened!" is a super toxic lesson to take away from
| a rare success where people came together and fixed something
| instead of firefighting disasters.
| victor9000 wrote:
| I've seen this phenomenon play out multiple times in my
| professional career, where a considerable amount of effort goes
| into creating a robust system only for the effort to be
| minimized by management due to its stability. Somehow
| preventing a plane from crashing is not as valuable as digging
| through the ashes.
| deepsun wrote:
| A lot of jobs are like that. Accounting, legal and security
| work is only visible when it was bad.
|
| Noone is being promoted for doing good job that prevented an
| unanticipated disaster from happening.
| HPsquared wrote:
| That's why presentation and "sales" type skills can be
| useful. A bit of doom-mongering internal PR about the
| problem, then present the solution. Don't just solve it
| quietly.
| pflenker wrote:
| ,,there is no glory in prevention".
| hibikir wrote:
| I have made a career if stabilizing systems... but the secret
| is that they have to be pretty close to on fire before I am
| ever called in.
| pimlottc wrote:
| And unfortunately sometimes you have to just let the fire
| smolder before anyone cares enough to let you fix it.
| throw0101d wrote:
| > _" Remember Y2K? Nothing happened!" is a super toxic lesson
| to take away_ [...]
|
| See perhaps:
|
| > _Normalcy bias, or normality bias, is a cognitive bias which
| leads people to disbelieve or minimize threat warnings.[1]
| Consequently, individuals underestimate the likelihood of a
| disaster, when it might affect them, and its potential adverse
| effects.[2] The normalcy bias causes many people to prepare
| inadequately for natural disasters, market crashes, and
| calamities caused by human error. About 80% of people
| reportedly display normalcy bias during a disaster.[3]_
|
| * https://en.wikipedia.org/wiki/Normalcy_bias
|
| Also maybe:
|
| > _Optimism bias or optimistic bias is a cognitive bias that
| causes someone to believe that they themselves are less likely
| to experience a negative event. It is also known as unrealistic
| optimism or comparative optimism._
|
| * https://en.wikipedia.org/wiki/Optimism_bias
| Terr_ wrote:
| I like the phrase "Self- _un_ fulfilling prophecy", for when a
| prediction that is acted-upon often invalidates its future.
|
| There's also this annoying catch-22 which may be familiar to IT
| staff:
|
| 1. Things go wrong: "What do we even _pay you_ for? "
|
| 2. Things go right: "What _do_ we even pay you for? "
| ASalazarMX wrote:
| And this is why everything goes in writing.
| takinola wrote:
| > "Remember Y2K? Nothing happened!" is a super toxic lesson to
| take away from a rare success where people came together and
| fixed something instead of firefighting disasters.
|
| My cynicism about Y2K comes from the fact that there were a lot
| of snarky articles written about how certain countries or
| companies were not Y2K ready but nothing bad seemed to happen
| to those countries either. It seems like a natural experiment
| was conducted and the results indicate there was no correlation
| between good outcomes and the work done to be Y2K ready.
|
| I have no doubt that the armies of consultants did fix real
| issues but anyone working in software knows there is a never
| ending set of things to fix. The real issue is whether that
| work was necessary for the ongoing functioning of business or
| society.
| Marazan wrote:
| When things got missed things went _badly_ wrong and that
| spurred businesses to take rapid action to respond.
|
| The first "Y2K" bugs where when banks' computer systems
| started messing up the calculations of long date financial
| securities/mortgages - decades before the millennium. Closer
| to the time Supermarkets started junking food that had a post
| 1999 Best Before date. Those were company ending problems if
| not fixed and so got overwhelming and rapid focus.
| arp242 wrote:
| > Y2K was a real problem
|
| Which only makes it more interesting. There are many takeaways
| one can have from this article, one of them is that:
|
| - Problem X is serious.
|
| - Y will address problem X
|
| Is incomplete reasoning, or even an outright fallacy. Just
| because it's claimed that Y will address X doesn't mean it
| actually will.
|
| Especially on high-stakes issues ("our business will collapse",
| security, safety) or emotive issues (social justice, security)
| this type of flawed reasoning seems to be a common problem.
| QuantumGood wrote:
| A LOT happened, and was well reported, just not widely. It's
| more that the _worst_ didn 't happen, and that's what the media
| focused on.
| intellectronica wrote:
| Same but 25 years in the future: "How I made millions, enjoyed
| unlimited prestige and an easy life as a fake AI existential risk
| researcher"
| gred wrote:
| Maybe AI risk is also higher in Asia and South Africa, and for
| the same reasons.
| PaulKeeble wrote:
| I felt a lot of relief on the morning of 1st when everything I
| had done was working perfectly. All the test showed that had it
| not been fixed there was a lot of data corruption.
|
| I have been through another one of these where one part of a
| company changed their year entry from 20XX to just XX to save the
| people entering it time and multiple systems did not defend
| against this and suddenly started calculating all intervening
| years from the time of jesus up to the present day! Its was
| catastrophic, that simple changed caused several days of disaster
| recovery but months of defensive programming work as well.
| Date/time errors can be devastating to business.
| ryandrake wrote:
| Stupefying that after Y2K, a company is willing to deliberately
| make this mistake to save two keystrokes. They deserve whatever
| bad will come to them in 2100.
| freddydumont wrote:
| The article is less about Y2K itself than it is about the
| absurdity of work in the corporate consulting world. It's a good
| read.
|
| I wasn't there for the play-doh management fad but I sure
| experienced capital A Agile and honestly can't tell which is more
| infantile.
|
| In a sense, the corporate environment of constant indefinite
| emergency described in the article is the same as arbitrary
| deadlines and non-stop "sprints".
| throw0101d wrote:
| Next up:
|
| * https://en.wikipedia.org/wiki/Year_2038_problem
| DennisL123 wrote:
| Feels very relatable. A couple of years after Y2K I was asked by
| the employer at the time to join an multi-billion internal
| project that was run almost exclusively by contractors. I think
| the task was to convert a Fortran monolith into Java, but after
| 20+ years it could also been Cobol.
|
| The biggest contingent of contractors came from a company of the
| AA universe that has survived the Enron scandal. My task was to
| advise on how to interface with a certain internal system. Easy
| job. The amount of actual code written was minimal and theses
| folks were big on generating class scaffolding from UML
| paintings.
|
| Funnily, there was a constant rotation of contractors and they
| didn't realize I was internal. So, I was treated by them as one
| of their own. And it was six weeks of education that you can't
| get in university or business school.
|
| I learned the art of being billable which is miles away from
| doing any work. Matter of fact the hour didn't have 60 minutes
| but a hundred. And whatever you faked doing, you did it with
| double digit precision. You documented that you documented
| someones proposed, ie. documented, code change that day. Two
| minutes spent, 1.89 hours documented. Yes, Github and stuff would
| only come the following decade. We are talking word documents
| here. Being billable meant that people would propose changes and
| retract the proposal with another one proposal. At least, the
| amount of side effects was limited.
|
| I also learned the art of fake process. The contractors didn't
| necessarily know what they were doing. But they knew of doing
| things. So, lots of meetings were happening and random
| ,,specialists" and ,,experts" were flown around the planet to
| delight meetings with stuff they knew of. Having these people
| disseminate some talking points from recycled slide decks was ..
| uhm .. fashionable.
|
| Third was the art of faking yourself. I vividly remember the guy
| coming in from Tuesday to Thursday who would bring and arrange
| the same set if golf balls at his desk. I must have asked him if
| he played or something. In the end it turned out some important
| dude made him caddy for an offsite golf event of some partners.
| And he picked up the balls that were lying around the course.
| Some consider that a big nono. But apparently it gave some status
| since every thought the guy had played at said offsite.
|
| Highlights from the weeks being embedded with the contractors
| include a contractor-only dinner. No idea anymore how I managed
| to be there but some partner gave a rousing speech how they were
| at the fore front of innovation with this project. And that
| everyone frenetically clapped at the end. Memory has that the red
| wine was good, the food less so. Another highlight was an
| educative session by one of the flown in experts on what a FIFO
| queue was and how that aided in-order processing of arriving
| events. Frenetic clapping ensued.
|
| Now this is all 25'ish years ago and perhaps memories are more
| pointy than reality was. What is certain though is that the
| number of lines shipped into production was zero. Zilch. And that
| was not because someone realized all of it was fake. It was
| because the company went out of business eventually and was
| bought, sold, merged for its customer base and not its systems.
| ryandrake wrote:
| Ugh, upvoted because I've seen this too. Lots of "businessing"
| being done so it could be billed, but nothing actually gets
| produced besides reports and talks and dinners and meetings and
| documentation, and then, the project gets quietly scrapped
| until the next one starts and it's rinse-repeat. It feels like
| perpetual money laundering of shareholder value into
| contractors (and employees, honestly, too).
| nycdotnet wrote:
| The 2038 bug is less than 14 years away at this point. There is
| an astonishingly greater amount of software out there compared
| with 24 years ago. I don't want to be a doomsayer but it's
| probably time to keep this in mind anytime you implement an epoch
| going forward.
| marcosdumay wrote:
| Almost all software is 64 bits nowadays, and avoids the problem
| entirely.
|
| But "almost all" is not "all", and won't be until there. It
| will certainly be interesting, as stuff will fail in a
| completely different way from Y2K.
| teractiveodular wrote:
| The problem is not so much OS-level support, but all the
| legacy databases etc storing 32-bit timestamps.
| marcosdumay wrote:
| Oh, yeah, there are protocols, file formats, old devices,
| all kinds of interesting things. But more importantly,
| differently from the last time, they are very different
| from each other, so much that it's hard to even anticipate
| what may break.
|
| I imagine a couple of days with the internet misbehaving
| everywhere is a safe bet.
| mrpippy wrote:
| Even talking about software running on servers, I think
| there's more 32-bit software than you assume.
|
| But my real worry is embedded systems, where very little is
| 64-bit. Almost every embedded Linux system, IoT crapware,
| Android anything. Almost none of it will be able to keep time
| after 2038.
| dsr_ wrote:
| Right now Debian is in the middle of making sure that all of
| the 32-bit software has 64-bit time_t. Descendant
| distributions will benefit from their work.
|
| Are other Linux distributions doing the same thing? Sure, and
| there was a lot of work in the kernel (mostly in the 5.x
| series) to get it all nailed down. NetBSD and OpenBSD already
| tackled it.
|
| But "all" can't be guaranteed, because people insist on
| keeping elevator controllers and industrial processes and
| anything which hasn't actually had capacitors explode and
| resistors melt running for an extra decade.
| imron wrote:
| A large amount of embedded software runs on 32bit and can't
| be readily patched.
| ninkendo wrote:
| > Almost all software is 64 bits nowadays, and avoids the
| problem entirely.
|
| Sure, we say that now, but 584 billion years from now when we
| use up 64 bits, we're going to be cursing our ancestors for
| being so short-sighted.
| aftbit wrote:
| >and an industrial blender at a cattle-culling facility in
| Alberta whose whirl wouldn't cease even when unplugged from a
| power source.
|
| What? We discovered a perpetual motion machine at Y2K and I never
| heard of it?
| aj7 wrote:
| Remarkably, Twitter had fake jobs for most of its history. Any
| new Stanford graduate in any field could have one.
| some1else wrote:
| It appears that the author was indeed not too closely familiar
| with the premise of the Y2K bug, as they mention the change "from
| 19 to 20"
|
| _... the Y2K Bug, and it prophesied that on January 1, 2000,
| computers the world over would be unable to process the
| thousandth-digit change from 19 to 20 as 1999 rolled into 2000
| and would crash ..._
|
| That wouldn't be problematic, since the numbers don't loop around
| (like when going from 99 to 00).
| le-mark wrote:
| A lot of these systems stored the year as two digits. So 19 to
| 20 wasn't the problem. The problem was mainframe based systems
| are/were almost entirely based on fixed length data
| representations; cobol copybooks, tape and dasd datasets (ie
| files). Expanding all those from two bytes to four was a lot of
| work and risk is some organizations.
| ChrisArchitect wrote:
| As of today:
|
| 2038 Epochalypse countdown: 13 years, 4 months, 19 days, 7
| minutes, 13 seconds
| ChrisArchitect wrote:
| A bit perplexing that the author after all that time
| thinking/working on Y2K isn't really clear on what the bug was.
| Nor that under all the spreadsheet filling, meetingnote-taking
| etc there was some IT deckhands running around updating PC BIOSes
| and making sure software updates were in place so ppl could keep
| doing their daily office work when they got back to the office on
| Jan...3rd.
| SturgeonsLaw wrote:
| It's not surprising at all that some corporate analyst doesn't
| know shit about the technical domain. I see it all the time in
| cybersecurity, there are two types: the hackers who understand
| the different layers of technology, how they interact, how they
| can be broken and how they can be fixed, and the checklist
| monkeys who don't even understand the questions they're asking.
| roca wrote:
| There is a very powerful myth taking hold that the Y2K problem
| wasn't real, but some kind of false alarm or scam. It's very
| strange and scary. It's not just isolated people getting it
| wrong, I see it popping up all over the place. We really need to
| push back on it.
| istultus wrote:
| I can't bring myself to read this monolith because the two
| premises at the top are wrong: 1. Y2K was a real phenomenon that
| needed fixing in various aspects, and 2. fraudulence is not a
| problem of "capitalism" - it's a problem of humanity. Hell, the
| biggest quote used to explain the Soviet economy was "they
| pretended to pay us and we pretended to work".
| coding123 wrote:
| A lot of IT jobs are fake. Moving numbers and data around so
| that, in the end, someone sees a graph to continue to make bad
| decisions anyway.
| JoeAltmaier wrote:
| Cute
|
| My sister's department reviewed every line of code in every
| product for date/time issues, and corrected them. But she was
| probably anomalous, by all the anecdotes. She ran a tight ship,
| and did things that actually needed to be done.
| Aurornis wrote:
| > My interview consisted of about twelve minutes with a laconic,
| mustachioed, middle-aged Arthur Andersen manager named Dick. (One
| of the services Andersen had been asked to provide was to help
| hire the Conglomerate's Y2K team.) "On a scale of one to ten,
| what's your knowledge of computer software?" he began. I paused
| for a moment, unsure of whether our interview would include a
| demonstrative component, as had so many previous interviews for
| jobs I had not gotten. But his office was empty. I couldn't see
| how he would test me. I said eight.
|
| On a private forum I'm part of there was an engineer who ascended
| into upper management at a startup. He had an entire thesis that
| modern tech interviews were bullshit and could be replaced with
| short conversations and asking candidates to self-rate their
| abilities.
|
| He posted long and confident writings about how he was going to
| save his company so much time and attract the best talent by
| having the shortest interviews and trusting candidates self-
| ratings of their abilities.
|
| He disappeared for a long time until one day he came back and
| wrote a post-mortem about his hiring experiment. The quality of
| their new hires had collapsed. It was so bad that some of their
| previous top employees were quitting because they were tired of
| all of the unqualified people joining the company.
|
| As he learned, if candidates sense that their interviewers aren't
| going to examine their claims too closely, many of them will
| inflate their claims as much as they think they can get away
| with.
|
| In hiring, it only takes one candidate grossly exaggerating their
| experience and abilities to push the truly qualified candidates
| into 2nd place (aka not getting the job).
|
| We all like to think that we can separate the liars from the
| truth tellers, but when you're trying to do it in extremely short
| interviews with questions going both ways, there isn't much time
| to deep dive.
___________________________________________________________________
(page generated 2024-08-31 23:00 UTC)