Worked on a project many years ago where the best tech for our situation was Microsoft Message Queue (MSMQ). Only problem was management didn't want to spring for the license fees. The directive was for us to build it ourselves. It went as well as expected ie flaky, badly written & undocumented. The irony was that MSMQ was included (free) in the next release of Windows.

Also ironic was that everyone their own (badly written & undocumented) string & date classes.

It went as well as expected ie flaky, badly written & undocumented.

So, just like MSMQ then?

It annoys me how people forget that staff actually cost money. And it gets worse once management start penny pinching. Why the heck do you worry about spending an extra £50 on higher spec monitors for your staff when you're paying your staff five or six figure salaries?

You get what you pay for, and then some, for not following the instructions.

Many years ago we had to put in some very small "servers" which were basically PCs running Windows Server - because there was no budget for a RAID controller, we just dropped in a 2nd HDD and set up software RAID to mirror the primary drive. Not an ideal solution, but it was quick to set up, didn't need any drivers and was sufficient for the needs of the client at the time.

Did that in some old MicroServers from HP. Far cheaper to buy those than a NAS, put a boot drive in place of the CD and then configured a software RAID

Took and absolute age to rebuild if a disk failed.

At least someone hacked the bios to support hot swap

We have a management system, hosted on AWS. It manages a few hundred machines, and has various scripts it can run on this machines to perform various functions. One script that I wrote zips up several logs on the machine it runs them on, then "attaches" them to the machine record on the server, where they are available as downloads.

I developed this script, but due to structural changes in my team, never used it, and never really even tested it properly. It stayed on the server, largely forgotten about by me until our server started crashing. The hosting company said that the attachments table for the database had reached it's quota (several gigabytes), and they blamed this script.. The script needed to be triggered by a system admin, as it was triggered by a certain event that could not occur normally (basically, using the agent software, we had to trigger the event manually, and it had a custom name). The other admins denied all knowledge of the script, even though they could see it (and how to call it) in their admin consoles.

Somehow, this script, despite generating and uploading gzip files that were around 100k on each run had filled up the attachments table.

When I was notified of this, I disabled the script, and the hosting company purged the attachments table, but it kept happening. Eventually, I got the hosting company to delete the script, and purge the table. This is when it settled down.

I actually believe the other sys admins when they say they didn't use it. They wouldn't have needed to use it 10s of thousands of times in a few months, we only have about 300 computers on the system and don't get tens of thousands of calls.

I think what happened is that I was testing the script, something went wrong, and the system did not register it had run the script, so did so, repeatedly. But because it wasn't reporting this on the admin console I have access to, and made the logs available for download (as it should have), I didn't know this, and thought it had completed sucessfully.

Thankfully, the hosting company has since agreed to give us a test instance of the server, so any future development can be properly tested before it goes to the live server. This is good, actually, because I need to write a few scripts we can run locally to automated some aspects of the management. We have the required API access for this, but I'm hesitant to let scripts I've written API access to the live data without rigorous testing.

Back in the mid/late 1980's my boss was asked to produce something for the Ferrari F1 team. (We did lots of techy things for the teams.) He decided on a TMS320 based solution (fastest DSP at the time), that I (as the only employee of the company - the boss worked for another shell) would design the hardware and software for. The problem was that the official TI assembler was about the same price as my yearly wage.

So, I had to write my own macro-assembler for the TMS320. It was a great learning experience and meant I knew the chip inside out.

The hardware struggled a little with noise on the dual layer PCB as 30MHz clock was quite fast at the time, but this turned out to be from the radio producing company next door! (It worked perfectly on a Sunday morning!)

I later rewrote a Javascript interpreter that was taking too many time and memory resources on a 4MHz 8086 Internet set-top box where memory was used for screen refresh for 50% of the time.

Getting "deep and dirty" is something everyone should do at least once to get a proper understanding of what is involved.

(Like every driver should spend a night 'on the motorway cones' to get an appreciation of that. I helped change the contraflow at the M2 jnct 5 one night. It is bloody scary standing next to cars doing 80+ in the 50mph limits imposed in such situations! - obviously pre-speed camera days.)

I was once chewing the fat with the heat of IT about why some of my co-workers didn't understand why what they were trying to do wouldn't work. The boss pointed out I was the only person who had any qualification in IT (I had a degree - a third rate one from a third rate uni - but it still counts as a degree). Everyone else had fallen into IT from very different carears (including the boss!) so they didn't have the holistic view of how a computer worked.

To fully appreciate your world, you have to understand how the areas around you work. It's so easy to design the perfect system that no-one uses because you don't understand the context in which your system works.

Getting "deep and dirty" is something everyone should do at least once to get a proper understanding of what is involved.

It was something they were very keen on at Newcastle Uni when I did my degree, even knowing that hand writing machine code wouldn't be something we'd likely need in our professional careers - an understanding of the fundamentals was considered a key skill.

I met a student from a another, supposedly more prestigious, University and discovered their entire computing course seemed to consist of learning as many high level languages as possible with very little emphasis on understanding programming techniques.

I still can't tell this one...

Professor with a hat icon, that's the closest I can get.

Obviously, he didn't want to embark on a last crusade.

Of course not, because otherwise he will have to do additional films, I mean jobs, for them down the line which will get worse, just like the last two films!