When civilisation ends, a Xenix box will be running a long-forgotten job somewhere We've all heard the phrase that "best is the enemy of good", but we've all also shoved in that "temporary" solution that ended up being a bit more permanent than we'd hoped. Welcome to the home of duct tape and prayers: Who, Me? Today's confession comes from a reader we'll call "George" (not his name) and takes us back once …
There is nothing so permanent as a temporary fix that works. The heat death of the universe will be populated with cockroaches, Twinkies, & all those "temporary" fixes that just kept going.
*Hands you a pint & clinks rims*
As someone whom couldn't code his way out of a wet tissue, I am in awe over those whom can not only do so, but can write such code that Just Keeps Going. Cheers!
Damn right there, even us cockroaches have standards
Meanwhile back in engineering , theres lots and lots of very old code thats never updated because.... it works, and besides it costs way too much to update it....
<<looks at the RS232 comms program we use.... last updated in 2006
I just finished off the last carton of Nestle's Double Chocolate Quik Powder (Best if used by 10/2008 presumably manufactured circa 2006) which I've been rationing for almost 15 years.
While here in USA the similarly-named 14-ounce ready-to-drink Nestle's Quik Double Chocolate Lowfat Milk is still available, the powder version has not been around since 2007.
I much preferred the stir-in powder form as, even upon vigorous mixing, there remained tiny crunchy "nuggets" of the mix creating a delicious (to me) bonus in every glassful. This phenomenon occurred even whilst fresh back in the Early Aughts and remained so right up to my final quaff.
While speculating this very effect might have led to its demise/end of manufacture, I have so far resisted searching for vintage containers on Fleabay etc. as MY stash was always stored in a cool dark location buried deep in the closet...
The Spanish chocolate drink "Colacao" (readily available in all Spanish supermarkets to this day) doesn't dissolve completely in cold milk and forms lumps, perhaps this would be an acceptable substitute?
(Spanish childhood can be divided into two groups: those who drink Colacao with its "grumitos", and those who prefered the lumpless Nesquik).
"I can still remember a very lubricated taste test in 1997 of MRE sachet food with best before date in 1968, manufactured date in 1963."
Must have been very lubricated indeed ... MREs didn't make their debut until 1980. Prior to that, the food was canned. Food packaged in 1963 would have been MCI ("Meal, Combat, Infantry, debut in 1958). The "Long Range Patrol" ration, available to the troops from 1968, was packetized, but was freeze-dried and required rehydration prior to sampling.
Well excuuusse me. The dates were printed on the sides but maybe old age (and much lubricant) has dulled my mind. The gent who found them in an old warehouse near Cheltenham said that the wooden crate was labelled mac/sog lrrp rations ?
I still remember the reasonably tangy taste of the barbecue sachet but the rest is a bit of a blur.
We did a similar test on good old British 24 hour rat packs and the brown biscuits live forever.
The best rat pack is the 1970’s New Zealand box which had real manukau honey in tubes !
Modern commercial versions are useless after their expiration date and tend to dissolve the packaging.
If you want to buy a fine modern rat pack go with the French version, the food and condiments are tre bon.
At my volunteer fire department hall, we recently were able to "dispose" of ancient emergency supplies, presumably cached in case the cold war heated up all the way here on the coast of Canada. Everything had been crated up for nigh on 60 years, still as good as new.
Much of the equipment was aimed at supplying a small field hospital, M*A*S*H-style. Cots, surgical tools, and large tins containing packets of crackers. I volunteered to eat one as a test.... while still technically edible, these never would have been considered "good." They were clearly meant to be standardized carb calories and nothing else, the tin was even labelled as how many calories per packet.
Ack.
My toolkit usually also contains C-Kermit. Available for many quite obscure systems as well so often common denominator. Scripting is quite flexible as well. Self-presevation mode in my brain is preventing me from getting into details of some solutions crafted with that.
As someone whom couldn't code his way out of a wet tissue, I am in awe over those whom can not only do so, but can write such code that Just Keeps Going. Cheers!
Writing code that just keeps going is easy; you just have an absence of things that can make it stop; therefore "quick fixes" doing one job tend to keep going (as you say) until the heat death of the universe precisely because they are simple and there is no possibility of them hitting any novel unforeseen errors because the code is so simple that there aren't any.
Them being a bastard to replace is usually due to the compressed design process being the single developer asking the sole user what it needs to do, and them producing something, and asking the user if that's right and then making a couple of minor tweaks.
The "proper" replacement fails because it's designed by committee with the requirements set by the manager of the manager of the manager of the person using it based on what they think the user is doing. Hence the requirements are wrong and the replacement fails to do the job as well as the "temporary fix", which ends up being near impossible to replace by ordinary processes.
> "I still wonder if it is still being used..."
Many years ago the company that paid me to sit at a desk bought a proprietary system from an american company. It ran (IIRC) Solaris 2.6 and was the epitome of a "black box" solution. Data went in and something useful came out.
The machine was locked up tight. Nobody in the company had access to it. No-one knew the root password. It never received any software updates whatsoever and it kept running.
It seems to me that provided the o/s and the apps are stable and that adequate security is implemented, there is never any need to perform updates - or introduce new bugs as the skeptic might describe the process.
Is it still running today? Doubtful, since external environments change and boxen that do not change with them become obsolete. However that little box was the "perfect" computer. it never needed maintenance. it never crashed. It just quietly got on with its job.
I suspect that if it had been allowed to, it would continue running indefinitely. Much like that Linux box that gets stuck on boot-up with "a start job is running ... no limit" report on the (text) console. That is, if the user knows how to get to the text console.
I keep my Vet's blood machine running. It's an original Idexx Vettest 8008, and is about 30 years old. It's up-to-date, though ... it runs a 22ish year old version of FreeDOS, because MS-DOS is no longer supported. None of the Vets or vet-techs who have run a blood panel on the thing know (or care) that it runs DOS, much less that it's built on a rather elderly PC. It's a single-purpose device, and air-gapped, so security isn't an issue.
I know of about forty of these things still in use here in the SF Bay Area, because I have worked on them. I suspect there are several hundred more. (I bought a bunch of used units 23ish years ago from Vets with Y2K worries ... I was speculating on the need for spares in the future. It was a good guess on my part. I have since augmented my stock by purchasing them whenever I run across 'em.)
Difficult. It boots and runs from a single floppy, contains no HDD, and the display is a rather small LCD. Most early units are 286 based, with 640K RAM. Later models have a 386, 2 megs of RAM and an unused IDE controller and unused ISA expansion slot. They all have odd memory mapping because of the LCD display, a small built-in thermal printer, and proprietary hardware for the blood work itself. I have never tried to plug in a HDD or expansion card, no point.
"Trigger's Broom if you're a youngster with no knowledge of the classics"
No no, 'Trigger's Broom' *is* one of the classics
(RLP really was as scruffy as his character in Vicar of Dibley in real life... just how the cuteness of Emily Lloyd sprang from his loins I do not know!)
So the 386EX actually got used for something! Back in the 90s I worked for a tiny company that designed PDAs. We had the Intel rep come round to tell us about this wonderful new chip. Intel never really got embedded, so we found it kind of laughable in comparison to the MIPS and Hitachi SH3 devices we were using. It was based on what was then an old process node, not the current, so it was slow and thirsty. And the low-power modes were pathetic. They really thought that we should be glad to get it. I may even still have the datasheet somewhere.
> breaking things in obscure ways
Oh yes.
Even when that "start job" is an nfs mount request to a system that has been turned off (i.e.the box being booted has had no changes applied to it since the last successful boot) AND that the mount options in fstab include bg to background the mount.
Bitter? Me? Yes please, I'll have a pint.
There were some versions of opensuse not too long ago that tended to hang on boot if the network wasn't available because some bright spark thought getting the time from NTP on boot was sensible seemingly the same bright spark then decided to make the timeout something stupidly long. (I want to say minutes but I'm not 100% sure on that)
Apparently no one thought it might be used on a laptop which may not always be in the same location (and thus the configured wireless network may not be available)
Try to boot AIX without network and with a NFS mount, as when you restore it from a mksysb backup. You'll be granted with enough time to get a pint (or three), wait for its effects, and take a not-so-quick trip to the loo. And if you had several NFS entries you've forgotten to comment out in /etc/filesystems, you might as well be able to order a pizza, go to the pub, grab a couple pints with the folk, come back, pay for the pizza, eat it, take that trip to the loo and then enter the root password.
I discovered around 2000 or so that the limiting factor to the service life of an ancient desktop PC in a piece of satellite ground test equipment was the coin-cell battery molded into its configuration memory and clock chip. Said clock chip having gone obsolete, the only solution was to Dremel my way into the chip, tap into the supply wire from the battery, and reroute it to an external coin cell in a holder glued atop the chip. Worked a treat, and the test gear continued to work. Such projects have a very long support timeframe.
I'd have gladly upgraded the PC (and we tried!), but due to a consultant's idiocy (and against the urging of the new engineer at project start -- me) we had chosen software that depended on a specific version of QNX, and whose vendor shortly went out of business (no upgrades!). That version of QNX had a clock counter overflow that prevented it from operating on anything faster than the original 33 MHz 80386 processor.
The next such system used Sun Ultra 5s, whose dead battery-backed SRAM and clock chips were at least still obtainable.
Solaris had an interesting bug for many years. Most telnet clients support a command such as "telnet -l username" to supply the telnet daemon with a user name. The Solaris telnet daemon forwarded that argument to the login process unchecked. As a result, you could get root on any Solaris box by typing "telnet -l '-f root'" on the client, which on the server side would spawn a process "/bin/login -f root", which logged you in as root without any further checks.
Oh the fun we had when we were students.
If you are reading this, you're probably using the hack that I put together in 4.1BSD (now called 4.1aBSD) for part of the TCP/IP stack to be included in 4.2BSD[0]. It was supposed to be one of those "Just get us through the demo, dammit!" hacks. I got 'er done over Christmas/NewYears break in 1981. Virtually every version of TCP/IP since has used it. Not too bad for a quick hack ...
[0] Just to cut the usual pack of idiots putting words into my mouth off at the socks, no, I didn't write the whole stack. That's why I said "part of". It is only about 120 lines of C in total.
Certainly not! Even as a callow yoof, I knew that realistic fleshtones were infinitely irrational and somwhat chaotic in nature, and thus uncompressable if realism was intended in the final display. Instead, we compressed UUCP headers in usenet multi-part binaries. Saved entire kilobytes per picture in early testing. Shame it never caught on ...
Pardon me while I get back to restoring my original 1944 Quick Turbo-encabulator.
...years ago I was at one of my favourite sites - I genuinely enjoyed working there even if it could be difficult sometimes.
Anyway, a new rack in their server room had gone in, replete with a new (from memory) 4.5kVA UPS. Alas, said UPS turned out to be faulty so when the electrician wired his 40A commando plug in and turned on the power, the whole building electrics tripped.
Irritating but not the end of the world (we did it twice just to be sure it was the UPS).
Everything that had gone down, did come back up and all was fine. Or so we thought.
Suddenly, no voicemail. At all. Not even an option.
Queue much hilarity (and panic) as no one seemed to know what drove said voicemail systems.
Purely by chance, one of the postroom chaps overheard us saying something like "there must be a server somewhere for this thing!" and asked us if by server we meant a big computer? Because if we did, he knew where such a beast might be hiding.
He took us into the post room and in one corner, literally buried under a 4 foot high stack of hessian postal sacks was an ancient Compaq server. Upon restarting it, it loaded Netware 3.1 and sat waiting for a login.
Queue more hilarity when they called the company being paid to support it to be met with "You're who? It's a what? Running what?"
They did eventually track down the login details and we were able to reload the voicemail software, but I believe there were some rather pointed conversations to be had with the support company.
Hats off to that Compaq as well - no airflow, no effective cooling whatsoever and it just ran and ran and ran completely forgotten about.
Seems to be a theme of Netware boxes running happily in odd places without any issues: https://www.theregister.com/2001/04/12/missing_novell_server_discovered_after/
I had a similar experience with on old Compaq 286 server.
This one had actually been put into a cupboard and forgotten about, still powered on, still running a single simple process and the up-time must have been in years as no-one knew it was there.
We rediscovered it when we had to change the IPX routing across all our, several hundred, servers to a new protocol (I cant remember the details). Unfortunately the default protocol was the old version so all our network traffic routed through this aging 286 machine until we found it and switched it off. We had tracked it down to a LAN segment, knew what device type it was, but then had to literally swarm into some offices checking under desks and on top of cabinets until one the the team found a couple of cable disappearing into the side of a cupboard. We turned off the machine for a couple of days and there were no complaints so it was then decommissioned.
... whipped out that favourite of command link jockeys, rm ...
Ungrateful DHs.
I hope he left with a nice check in his pocket.
I would have dropped in a cron script that would run every six months.
It would print out a service requirement with instructions to call me to fix my lousy software.
And charge accordingly for the visit each time.
And if not called, stop the bloody thing in its tracks within a week.
Lousy software indeed ...
O.
Ah, yes, but the main bit that wasn't compliant was probably just the user interface that only accepted or displayed two digits for the year when trying to set or display the date.
As 32 bit UNIX and derivatives use a 32 bit signed integer for the number of seconds since 00:00 on 1st January 1970, the internal clock is just fine for keeping time, at least until 2038. It's the human readable bit which had problems.
Of course, the hardware clock which kept time when the server was off can also be a problem, but how often do you boot a UNIX system (I remember one problem on an IBM J30 where the clock battery was in the I/O cage that was removed when you had to install an I/O card, resulting in the system losing it's time when expanding the system. A Bull designed system, not IBM really).
There were also a number of leap second and leap day problems in the conversion to human form on some vendor's UNIX systems, which were easily fixed, but obviously would not have been applied to a system that had no maintenance done to it.
Our first interaction with American marketing people. They ask if we were a Cadillac or VW brand.
Oh definitely VW said the entirely European engineering team. Reliable, sporty , German engineering, (this was the era of Golf GTI not dieselgate)
Not some fat poorly handling, fuel burning American junk driven by old people.
Did something similar with a website review system at a certain phone directory company, but in my case it was a mess of VBA code that did it's best to stick together a wild array of office documents and analytics feeds. Saved £200k - £300k -ish of labour per year, my manager calculated at the time.
It was still there when I left.. it was even being rolled out to other products / teams.
I had a go at re-implementing a data transformation tool used when migrating data from a mainframe to a UNIX system. This was not so long ago, the tool was written in Java (of about 16 years ago), and I did it as an exercise in system resource utilization and the efficiency of the standard UNIX tools.
Java took >10 hours to run, and ended up chewing up all of the memory of the system.
Mine (written in awk) took about 40 minutes!
I admit there were a small number of corner cases that I did not cover (but nothing like the 80/20 rule), but that was just a matter of recognizing those patterns, and taking appropriate action.
But the Java version remained the official tool.
But when COBOL was king, chances are that the systems were small, and every byte of storage saved was important. That was why a lot of programs written in the 60s and 70s used a one byte packed decimal field for the year (at least on systems with 8-bit characters).
It was not COBOL that was the problem, it was the coding standards of the time!
I was told to use that format against my better judgement for some RPG code I wrote in my first job, in the early '80s. I was told not to worry about it by the Data Analysts specifying the program, but I left a comment in the source saying that it would break come 2000 anyway.
I often wonder if my code was still in use in 1999/2000. If anybody had any incorrect parking fine reminders in Rushmoor Borough Council in 2000 because of date arithmetic problems, let me know!
> never name a server something-temp
This is possibly the most important lesson I ever learned.
Also if there is any chance that you might in future need a second system doing the same job. be sure to name the machine something-1 put the number in right from the start, there are few thing more annoying than:
something-server
something-server-2
You could also start numbering with 0 if you like, but I find it confuses management.
Or maybe that is just me.
Just got off the phone from a project manager who explained that were trying to get a replacement for a faulty Cisco router in one of the data centres but the one that the maintenance guys had in stock was a grey import and Cisco wouldn't add it to their maintenance contract... "If I get you *another* replacement, can you config it for me"... "sure, but you've got a 'brand new' one (from 2018) sitting on the shelf behind me"
That would be my reaction If I got a call from some place I haven't worked at in 5 years complaining about some fix I put in that suddenly stopped working. Sure, I'll be more than happy to fix it... once we agree on compensation. P.S. My rates have increased since I last worked for you.
As an ex-labtech/it support guy for the NHS, I assumed the article meant Diagnostic Pathology Lab rather than a business.
If so (I'm making a lot of assumptions here, I know) then the regular report was probably the Cancer Registry.
If you work in NHS diagnostic pathology and someone asks for help with that particular report database, then you give it gladly...
Altruism rules OK!
As a tester I always thought a power off was a good test.
A fast shutdown is not the same, it has time to write data out to disks etc.
A customer found a problem when there was an emergency power off.
As part of 2 phase commit you have to write to one disk, then write to the second disk in the right order.
We found the first write was a write to the disk buffers - it was not actually written to the spinning disk (there was a 10 millisecond window)
At recover time the data from the first disk was not there, but it was from the second disk, and the system would not restart.
Particularly if the server in question is equipped with spinning rust. Disks which have been running continuously for years after their best before date may need to be persuaded hard to start spinning again after power down.
We had a license server (a SPARCserver) which have been on for >10 years. Nobody wanted to touch its power switch, but then it had to be moved physically. It was a rush job to keep the disks from cooling down too much. Fortunately, it came back alive and was still running when I heard about it seven or eight years ago. I don’t think it’s running anymore, but tough little bugger it was with more than 20 years of service.
After years of working in IT transformation, I can't recall how many times I've read/seen the word "temporary" on some old papyrus, from 10+ years ago !
When I hear this work, it literally means, to me, "terrible kludge solving the issue and triggering some crazed stuff for someone else in the future". Red flag all over the place !
I'm apparently earning good wages by being this "someone else in the future" :)
My second UNIX based job at a local authority. They still had an ICL mainframe for CTAX and Benefits. A predecessor of mine had put some hacky shell scripts to move files on and off the mainframe which didn't talk tcp/ip (OSLAN for the nightmares). They were supposed to be a temporary fix but then grew into moving files for interfaces twixt UNIX boxes and then this new fangled windoze stuff. Over the years, I never got around to really sorting it out and wound up extending them more and more. Others wrote their scripts to use these so when I tried to update it a bit, first with SAMBA and then web services I was told it would be too much work and to keep the shell scripts in place.
I shouldn't complain though as I finally got my head round shell - ksh then and then bash.
It is the year 2087. After the great plague, a team of intrepid whizzkids travels the now empty countryside, searching through abandoned buildings to find the hidden digital treasures within. With their skills in long forgotten codes they intend to find out the function of these strange boxes, hidden in corners and backrooms amongst the detritus of a civilization long gone.
It's worth noting that Vernor Vinge's far future SF has software archaeology as a known profession. With this lovely quote
Take the Traders' method of timekeeping. The frame corrections were incredibly complex - and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely ... the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind's first computer operating systems.
Hmm. A contractor in networking told me this one. He was doing a job for an airline we shall call English something scottish at an airport south of London.
There was a network and some PCs, but they also had a UNIX box and a load of ASCII terminals and printers that did the real work of putting passengers onto aeroplanes.
Snag was that pulling serial cable to add or move kit whenever anything changed involved taking the airport apart, which was frowned upon. To finish what he was doing required a major business change which had run head on into this snag.
As a quick 'n dirty fix to keep 'em in business until the next airport rework, he wrote a quick DOS TSR with a config file and stuffed all their PCs with serial cards. Wires ran from the box to the nearest PCs and from terminals to PCs plugged into the network around the airport. Config virtually patched port a to port b etc over the network.
This was still in use and had become the preferred connection method, when our airline was bought out by a larger one we shall call English something flying well over a decade later.
Did the same thing at a certain British "doesn't appear on OS maps" site.
Due to the legacy of the 80s and IBM Salesmen's generous entertainment allowance - it was wired with token ring.
The token ring cards only worked in some extremely obsolete IBM MCA bus machines running some IBM only flavor of DOS.
So I wrote a little TSR app that read/wrote to the the virtualised serial port associated with the token ring card and then copied the bytes to the 'real' serial port at 3F8. So everyone's normal PC had a very large and originally very expensive RS232 dongle under the desk.
billg, 1984: listen, just knock up something that looks a bit like Gem, and we'll buy Xerox in a year or so.
sadnad, 2016: listen, just knock up something that looks a bit like a kernel, and we'll be on Linux in a year or so.
sadnad, 2021: listen, it's been two decades, can we fix printing this year?
When a new COTS system was being put in place there was a bug that shrunk a fixed width file by 9 digits when the field was blank, and another that did the same, but then performed a calculation with the misaligned fields. The fix was to be deployed shortly by the vendor and they needed two temp jobs to correct the outputs before the next processing step.
The temp programs were called the Calculomangler and the Defloobler. Years later, when returning to the same project, I was surprised the fix had not been made and the program names had been added to the daily process documentation.
First saying is the correct one. Usually directed at inexperienced and energetic engineers who want to create a perfect system and in the process either:
A) delay the project development until you get a huge bloated and expensive mess or:
B) take something fit for purpose and "improve" it, leading to issues due to unanticipated side effects (ref STS-27 and the new "improved" tank foam)
1994 or so, I was tasked with setting up our office's internet connectivity, and needed to set up an internal DNS server. The first choice was to use a spare SCO Unix system, but the DNS server implementation running on that was horribly out-of-date. The second option was to install a DNS process on a server running the core OS we sold, but the only DNS implementation for that just wasn't yet up to scratch.
So I grabbed a surplus 386SX machine which had previously been running Windows 3.1, downloaded some Slackware Linux floppy images, and had a working DNS server up and running to tide us over until I could source something better.
It was still running when the company went bust around 2000, surviving an office move and merger in the process.
George wrote his program to do exactly what was needed and nothing more. Nary a bell nor a whistle, unlike, I assume, the never implemented replacement system.
This article should be printed out and shown to any user who comes up with a 'nice to have' requirement.
Completely agree. When I set up a system, half my time is spent making it work. The other half is spent simplifying it and designing failure modes. My job is easier, and coworkers are more willing to help with support.
I recently asked a user to be more specific in a request. She replied "well, if it's easier for you, just give me (2 smaller things.)
"I'm not asking you what is easier for me. I'm asking what you require to do your job." She then figured out that none of it was....
My late uncle worked for ICL.
When I was a kid he brought me bits and pieces such as core stores, magnets from printers and all sorts of stuff. He fired my imagination and a desire to work in electronics / communications. When I was at school he gave me dead boards and I learned my soldering skills desoldering 7400 series chips off the boards and more than anything else he gave me the confidence to go into engineering. When I went to college and poly he was there for me and gave me lots of encouragement and kit to play with.
He was my mentor and whilst he was a cantankerous old git sometimes, he was a real shining light in my life. Great bloke, hence the pint.
Upvoted for the ref to someone in the past who inspired you.
With me, it was a bit different - a totally non-technical family didn't know what to do with me, but by chance introduced me to a bloke names Bill Higgins. He started me off in the wacky world of electronics and radio, and the mighty Mr. Geoff Osbourne at the local technical college took over later on.
Sadly, Bill died before I got a chance to go say thanks, and I've lost track of Geoff... if you somehow read this, Geoff, thanks for the advice and education. Who am I, you ask?...remember the evening with the reel-to-reel TEAC and the Jazz Band :-)
Great story! You were lucky to have someone like that to encourage you.
A friend of my mom's gave me a subscription to Scientific American for my 12th birthday. I could barely understand the introductory paragraphs, but I had already figured out science was my future by that time. I think I owe her a large chunk of my PhD for giving me "permission".
It does, sadly, work both ways. Entering high school massively interested in science and good at maths I met some truly crap teaching in those subjects, a mixture of teaching by rote and bullying. Since I loved reading and met some decent and enlightened teachers there my 'A' levels and degree were a mixture of English and social sciences.
For decades ( happy and successful though they've been) I've known this was wrong for me. I wouldn't change it for the world, but I do wonder what would have been the outcome if North Manchester (boys) High School hadn't been so crap in the early 70s.
And not to "play the gender card", try also being a girl in the days when we were explicitly forbidden to do subjects like technical drawing over home ec, etc. Being actively discouraged from doing sciences, especially physics, "because you're so good at French and German". Actually, I was equally good at the sciences and languages before being forced down the "arts" stream. At least the typing eventually came in handy. Never saw a computer at school.
We weren't middle class - no techie people in my family or family's acquaintanceship. No engineers or scientists or any such type. Our most sophisticated bit of kit in the home was a VCR. In fact, I was the first person to go to university in my family, studying linguistics. Thankfully, I fluked into a philosophy module that taught propositional (aka Boolean) logic - I didn't know its relevance to computing circa 1987.
Dropped out of uni due to utter boredom and didn't lay my hands in anger on a computer till the mid-90s. My girlfriend at the time was doing a masters degree - she had a computer for writing her thesis and emailing and exciting stuff like that. Something when "bing!" for me then. Went to uni and did a couple of modules in computer science - ahah boolean logic - and coincidentally got a job in a publishing company that was doing very interesting things with SGML. (No, not an oxymoron.)
By 1998, I was in the UK, working in IT - thank god for Y2K shenanigans and the lack of bodies to do the grunt work - and here I still am running key tech in a pretty large state govt environment. As they say, access to all kinds of things - such as occupations that suit your mindset and abilities - often depend on "intersectional" forces. So for me, class and gender definitely had a synergistic effect. I'm white, so I can't imagine if you threw in having a skin tone darker than a brown paper bag on top.
Well, actually, I can imagine - there were plenty of bright people I went to school with (a poor, majority non-white school). Some have become teachers, but aside from one notable exception, the only other non-white person in my class now in a STEM career is of East Asian descent. At least now, with tech pervading all levels of schooling, it should be easier for kids of any background to get into IT. Somewhat, at least. And hopefully not through a set of entirely random flukes.
I was 3 years ahead when I left junior school thanks to lunchtime lessons from teachers who really cared.
I went with my peers to the local "Comprehensive" as our Local Education Authority (LEA) had dropped the 11+ exam that year (mid '70s). It was the old "Secondary Modern" and was only used to the children unable to pass the 11+. The form groups were even called 'e', 'q', 'u', 'a', 'l', 'i', 't', 'y'!
I spent the next 4 years bored and getting into trouble with the teachers (including when the teachers line of thought was very obvious, answering the next question they were going to ask rather than the one they had asked.)
I had an at least weekly trip to the Head Master for a caning, always with the teacher in attendance to make sure that I was caned. As soon as the teacher left, the Head Master always apologised for the situation and explained he had to cane me otherwise the teachers would walk out! (They were as left wing as the LEA.)
It was very comprehensive though with boys and girls doing all subjects. As a boy, I was not too pleased with the repercussions of winning the school prizes for both Needlework and Cookery in the first year! I never made that mistake again.
I just scraped into the local Poly, where I started to get interested again. I always left the 3 hour exams after the 30 minutes you had to sit in your seat was finished, and one lecturer only gave me 99% - docked 1% for not going to his lectures!
And there is a *fabulous* book about LEO too. It is utterly worth a read. It's 'A Computer Called LEO' here: https://www.goodreads.com/book/show/1009975.A_Computer_Called_Leo.
OK, so the data warehouse was under development. Me, as an architect, wasn't supposed to touch code, but "as a stopgap", disparate sets of users needed some daily reports and I knocked something together including a little command-line utility that would email a file to an address etc. I think you could change the "from" address in the arguments too. So there were three bits to this:
1) A bit of code that extracted the reports
2) A bit of code that emailed files
3) A batch file running on the Windows scheduler that ran 1 and variations on 2 for the different customers
Over the next several years, the data warehouse did not materialise. Also because my solution was a "stopgap" it ran under my AD account rather than as an offical service. So when redundancy happened, I was "No, I don't want to work my gardening leave and you really must disable my AD account straight away".
There was a time when a mobile operator wanted to show off being the first one to deliver an international MMS message.
Alas, not all the infrastructure pieces promised by the vendors were considered completely ready for the show, so an additional layer of insulation (think of an application-level firewall/router, sorta) was desired to be installed in front of the actual inter-operator gateway.
What the "firewall" thing actually was was a "sendmail" software with very manually crafted configuration, for doing validation and sanitizing of the MMS inter-operator protocol (which was/is SMTP with some extra data items). Didn't want to look at any sendmail.cf/mc for quite some time after that project..
And as it happens, even though this was originally intended to be used just for the congress demo, the same piece ended up running in the production for at least a couple of years.
I really hope he charged them a LOT of money to fix that. I would've charged £25,000 to fix it. Just because it wasn't my problem anymore. I've done a lot of these in my day.
My favorite was the one where I started as IT manger in 2005 of a video production company which had never had one before. Just part time contractors who dropped in now and then. During the second week I was setting up a new email server for them. I had gone to run an errand at lunch and got a panicked phone call saying email was down. I got back to the office a few minutes later and it was the exact same problem. Disk was full. I cleared years of old logs and rebooted it and it was fine.
For my trouble I was fired the next day. They told the unemployment people that I "crashed the email server on purpose." I told the woman "why on earth would I create more work for myself?" Which made her laugh, and I got my benefits. I later found out that the people who ran the company were nuts. One of them had fired an entire department of people over the intercom once before.
I do remember doing some work for a government scientific organisation after I had moved onto a higher paying IT contracting job, because no-one else knew how to modify the awk scripts used to generate the labels that were printed out and placed on the plant specimen folders. Nice little earner, ~$1000 for a 4 hour job that I managed to smash out in 2 hours, including having to reset my own account (because I still had the administrator password memorised)
In my first job, worked for Eliot Brothers/Marconi Avionics/GEC (depending on the day of the week). The entire business ran on a homebred system on ICL mainframes. I shipped ship before 2000, but going into that, they were replacing the system because ICL no longer existed, and as I understood it, even the OS would fall over once the magic year change occurred.
On the subject of stiff that just works, there was another temp program running on a digital VAX that just never needed anything done to it. Until they turned the machine off one day to move it, after working for good knows how many years. It didn't come back and no one even knew how to get the program/ data from that machine to put on another cluster. It's a problem with long projects when even the apprentices at the start of the project retire before it finishes!
Surely " It's a problem with long projects when ".. they aren't documented and/or taught to new staff as time passes.
I can only make this assumption form my own (non-it) work, but we always initiated new staff into projects that we intended ( in education it's a forlorn hope*) to continue past our own tenure.
*It doesn't matter how good an educational method is, some bugger will come along and decide we all have to do something new, which usually means reinvent some squeaky wheel from yesteryear. A general rule of thumb is that the better something works the shorter its life span**
**No career minded education officer want to let a working project just continue . That's not the route to promotion.***
***The route to promotion is to start some new thing off with a blaze of glory then jump ship before it crashes.
One of my first "client' jobs after I moved to [insert large IT company here ... the one that recently spun out its services arm into a brand new, if wierdly named, company] back in the late 1990's. I was assigned to a customer that had just upgraded their mainframe system, and took the opportunity to update their operating systems and software stack now that they had a new shiny mainframe to run it all on. I was the mobile workforce "sysprog with a laptop and company car" that was doing most of their software upgrades. I came across one file transfer process that was taking literally hours and hours overnight every day using some very expensive vendor product to move large mounts of data between the mainframe and some mid-range systems. Apparantly, back in the day they used to use this software product for lots of data transfers but now this was the last one. So yours truly gets out the toolkit and basically rewrote this data transfer process from scratch using just standard operating system utlities (for this speific operating system, that meant JCL, VSAM, REXX and TCP/IP FTP). First time it ran, it moved a couple million lines of whatever the dataset was in about a tenth of the time the vendor file transfer sofware used to. In fact it finished so quickly, cue lots of checking to make sure the results were the same, and as expected. Yup. Give it a couple more days of running to make sure that one time wasn't a fluke. Passed with flying colours. So the customer terminated their expensive software licence and just ended up paying my erstwhile employer a few £k's worth of my time on a daily rate basis for code I'd plastered with "Bespoke customer code to perform a specific task" and "No support is implied or intended" disclaimer comments all over it. I move on to other projects, other customers, different systems, years and years go by but occasionally kept in touch with that first client. Every time they'd say "Remember that FTP pprocess you wrote in REXX in a few days? Well its still churning away, never had a problem with it." Last time was when the client techie I'd worked with retired a few years ago. His signing off comment was "That FTP thing you wrote is still going. But don't worry, I didn't leave anyone your contact details when I left." At that point it was over 20yrs since I'd cranked it out and hoped for the best, fully expecting to be contacted after a couple weeks when it stopped working due to running out of disk space, or encountering a dataset format it wasn't designed to cope with. But nope, nothing. Fire and forget software inc! LOL
Saint "George" of the Merciful Patch is far too forgiving. Anybody that came at me about my "lousy software" would get an earful about their lousy attitude and a report system that continues to not create reports.
Well, either that or a exorbitant bill, with each instance of verbal abuse itemized.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
