I used to work for an ROV (Remote Operated Vehicle) company that dealt with the oil and gas business.

I was employed to "deploy" their time recoding system. Basically go to a ship / rig install a computer and add the software.

The software was Sooo bad.. it was written in Paradox.. every report was formatted for letter where the regions I was to deploy it to was A4.

So being young and helpful,and having studied computer programming, I tried to modify the reports.

Every one of them used a different print routine.

The "Developer" (I use the term loosely) couldn't figure how to do hours and minutes so used hours and decimal parts of hours (so 1 hour 15 minutes would be 1.25 hours)

In his defence he was a diver before he became an ROV pilot and had written a tool to help himself which was then taken by management to be deployed world wide (my first real deployment was in Africa but that's another story).

...written a tool to help himself which was then taken by management to be deployed world wide...

And there we have it, in plain writing: Management only makes things worse.

> The "Developer" (I use the term loosely) couldn't figure how to do hours and minutes so used hours and decimal parts of hours (so 1 hour 15 minutes would be 1.25 hours)

Once I had to make my program produce a CSV that included some durations. The client wanted the duration to be human-readable, so that 1 hour 15 minutes should display as 01.15. The client then proceeded to open this in Excel, have it sum the column, and complain to me that the sum was wrong. -_-'

The correct display should have been 01:15, perfectly human readable and Excel will sum it correctly.

The correct display format is locale dependent.

The correct display should have been 01:15, perfectly human readable and Excel will sum it correctly.

Not as consistent over time as one might have thought.

I was reading a crime novel published pre WW1 where the two Sherlocks after consulting their Bradshaw went to catch a train leaving at 1.5 pm. Puzzled YT for a moment as it seem odd that the £sd lb&oz thinking Brits of the time would render half past one o'clock (13:30) as 1.5 until the penny (sic) dropped that 1.05 pm was meant and that 13:50 would be 1.50. I have subsequently noticed the same in other writers of the period so I imagine it was a common convention in timetables (including Bradshaw) of the time.

Just had a look at the [1]digitised 1910 Bradshaw on Hathitrust I can see this was the case. Fascinating resource for the period.

[1] https://babel.hathitrust.org/cgi/pt?id=umn.31951002200476y&view=1up&seq=5

We had a "professional" (pro in ... herding cattle?) named John or Clint (or one of the other cowboys). Charged external consultants rates.

Did not know about the type "date" or "datetime". The guy converted all dates to strings.

Lots of dynamic SQL just pasting unsanitised input together.

Views using views using views "views all the way down"

DB had no keys. At all.

DB had no index. At all.

And some colleagues still treat his code as gospel. I woudl like to do some "maintenance" using a stake and holy water. And on the data base as well.

(and I'm not even a good programmer, or a DB expert or formally trained in these things, or.... but I can still see these things

I actually and honestly prefer Fortran 95 or R)

I need one of these to numb the pain --->

Thankfully I'm now responsible for other parts of the project.

I started working on extending an image processing tool set developed by a previous researcher, and on the whole, the (mostly Pascal) code was well structured and neat, except ... comments were "sparse", and most often limited to

(* oops! *)

or the more mysterious

(* wulf! *)

The latter was an odd catchphrase of said researcher if something unexpected occurred. Furthermore, most variable names were most often single letters, with the worst offender usually 'l' (lower-case L, so easily confused with '1'). In later years I could always tell that a piece of my own code was written shortly after a visit to my former colleagues work, because variable names were (considerably) longer than usual, and the density and clarity of comments were considerably higher.

The worst bit of report writing I've seen wasn't even by an amateur, it was from a professional consultant (who'd probably reused it from somewhere else).

Instead of using the VAT value field from the data table he'd used a calculated field of VAT = VALUE * 0.15, which wasn't necessarily the case when the report was written and certainly failed when the standard rate changed to 17.5%.

There was another report which wasn't working and apparently this was preventing final sign off of the ERP implementation* so the consultant decided to come in to our office and, "Could I bring a junior with me for the experience?" That was fine with us, except that they then billed us for two people, for a day, at £1,100 per person per day when one had sat around the whole time with a bemused look on his face and the other had spent all day working on the report and still failed to fix it. Despite my lack of knowledge of the ERP system and reporting services (I'd come from AS/400 environments and was new to SQL Server) it took me about two hours to find and fix the problem. I rejected the invoice but I think my boss paid up in the end just so the project was completed.

*I'd come in after the implementation was supposedly complete, it took another two years before I resolved most of the issues.

> one had sat around the whole time with a bemused look on his face and the other had spent all day working on the report and still failed to fix it

Which was which...?

What about IF YEAR > 50 MOVE 19 TO CENTURY ?

This hack created a million jobs between 1997 and 1999

"This hack created a million jobs between 1997 and 1999"

No, that had been almost entirely fixed before 1990 ... the kludge you are thinking of that was creating jobs in that time frame was HTML.

We won't talk about the dot bomb bubble ... nor today's AI bubble.

I had to help remediate a coding nightmare that I made...

Years ago I wrote some shonky code - not surprising it was shonky, as all my code is sub-par; I am not a good programmer. This code was a quickish hack to get someone off my back cos they didn't have a scooby how to solve a problem. It involved Adobe API calls from a MS Word Macro IIRC to take RTF documents and draw them rather more prettily than they started and output a PDF.

Needless to say, years later, someone plonked their arse down beside me and said "this code you wrote doesn't work any more"

My initial position of denial of any involvement didn't stand up well in court, owing to the comment at the top of the macro claiming I wrote it. Never mind, deflection of blame is second best!

"Not surprising" says I "Adobe changed a load of stuff between then and now. No one paid to maintain the code. I haven't looked at it in years. Tough titties"

Then came the dreaded statement "Well 'we' are going to fix it, we just need you to explain how it works". Much mirth and hilarity ensued and I learned never to add my name to anything I wouldn't stand by many years later.

Guess I shot my own feet by not bothering with copius comments... I had to unpick how it worked was supposed to generate the reports and they re-coded it, I trust rather better commented and structured.

Always put someone else's name at the top...

That's why I always compare the name against svn/git blame...

Always put someone else's name at the top...

Even better than the plausible deniability of anonymity. Superlative if the moniker is of chap who was already deceased when he wrote it.

Many moons ago I was maintaining and on prem ITSM system, and as with many, it is easier to use direct queries for reports than anything provided. So I wrote a whole bunch of stored procedures.

A few years down the line and someone was still pulling some data from that system's DB - no idea why, we moved off about 4 years prior. I was asked "Is this one of yours?" I looked and knew damn well it was. It took me ages to work out what it was doing and to make the changes.

At the time I created the Stored Procedure I could write things like that so easily. 4 years down the line and not doing any SQL work - arggh

comments would not have really helped on that

I used to put my name at the top of most of the code I wrote ... right alongside a disclaimer which said plain as day that I was not responsible for the content, the performance, any loss of user data, upgradeability in the future, and about half a dozenish other things, some of which changed with the weather and/or the client.

I still occasionally get email asking if I could help with shit I wrote three or more decades ago. I always reply with my standard rates. Strangely, they rarely get back to me.

There is code I wrote for University course work that I do happily update (for free), when asked. That's becoming rare these days, alas.

Many years ago I worked as an IT analyst at a UK University's Psychology department. I provided tech support, maintained a few basic servers and also did programming for experiments (programmed in C++, accessing external button boxes via parallel port and utilising DirectX to ensure millisecond-precise timing).

One of the PhD students had been given a program by his supervisor (a senior lecturer) for him to tweak as part of an experiment he was planning. The PhD student couldn't get to grips with it and asked me for help. Foolishly I agreed.

Good god, I've never seen such a spaghetti-mess of code. No consistent indenting, no comments, one massive and convoluted block of code without any supplementary functions, numerous bugs - including two bugs that ironically ended up cancelling each other out such that the program just about limped through the supervisor's original requirements. I scratched my head over it for 20 minutes or so before deciding that the best (and quickest) thing to do was to nuke the entire site from orbit and re-write it from scratch.

So that's what I did. Got the requirements from the student and wrote the program from fresh ensuring it had proper indenting, used well-defined functions, a header file with constants clearly labelled so that the poor PhD student stood half a chance of being able to subsequently tweak the code and parameters for future use. Final program worked a treat and it was certainly a lot easier writing good code from scratch than trying to salvage the pig's-breakfast I was presented with originally!

Some code is simply beyond saving...

So many time, in my brief (5 years) career in dev, have I learnt to press the NUKE button !

Every time because of a poor sod with 0 understanding of programming and even less of the language he was instructed to use, was long gone & no-one had a clue how to update this ... Write once, read or update NEVER.

I remember a Fortran program (/spit on the floor) used in particle collision research, used to scan tapes used to collect events, looking for specific event.

All spaghetti code, use & abuse of goto, functions ? what is that ? The thread of it all was undecipherable to the point I thought part of it was actually never reached !

Worst of all: the program was having a fortran source as parameter that it would compile & run on each event !

Performance was atrocious which triggered the need to review it.

2 days in this mess & I nuked it and rewrote the whole thing in a 20th century language (aka, C) ...

A lot of the code written for the various particle physics labs was written in Fortran. It wasn't all bad. If it was, I wouldn't have spent as much time as I did at SLAC ... Some of it would have undoubtedly benefited from being re-written in C, but the folks actually using the code day-to-day only knew Fortran.

They still use Fortran in that world. It's not everywhere, perhaps, but it's pretty common. When in Rome ...

Poor code - just needs tweaking, this is a classic common decision process repeated across the IT world many times daily.

But this is from a Psychology department senior lecturer, are you certain you weren't being used as a problem test subject?

Back in my youth, was working for local council computer department when they had a full mainframe rig, was tasked with writing some Cobol code for the benefits section and was told off for putting in extensive comments, as they complained how much extra memory it would take when running on the mainframe. They couldn't grasp that the code was compiled, and comments ignored, so being the junior, I ripped out all the comments. I had a phone call from my old boss a few years later after I had left asking if I knew why such and such was misbehaving after they had done some code updates but they couldn't follow the source code, now leaving on good terms with him, hoping to return if possible, I told him I left a copy of all my code in my notes folder, hidden at the back of the old fire safe that held tape backups and disaster recovery stuff. Met up with him the next weekend and he got me well and truly wasted on fine ale.

Let's not forget that Horizon, Birmingham Council's Oracle implementation and every IT fuck-up in the NHS were all written by professionals. In IT, as in so much of life, Smol's Law[1] applies:

A professional knows exactly how bad a job they can get away with, while an amateur does the best job they possibly can for the love of it.

[1] I first heard this expressed by the wonderful Gaby Smol.

That "developer" was in the limbo between knowing enough to break stuff and not knowing enough to get something done. And, possibly, believing they "know stuff". Developing-wise, these were some of the most dangerous people I've met.

... (not closely, thank the gods) who thought that he was finished his assignment when he'd found a set of inputs for which his code worked. The idea that he had to keep going until he couldn't find a set that didn't work was utterly beyond him.