CubeWorld - Where's my key?

I bought CubeWorld back in the day, and I just heard it was actually released, this really annoys me that I've heard it's been out ages... and apparently wasn't as good as the demo even in the end.

But the really annoying thing is that apparently early buyers like me were meant to get a code to play the game?!?!

Where's my game key?.... What a total cock up he made of that game.

The Hot Water Pipe Balls Up

The worst mistake I ever made as a kid.... Was flood the house.

Yeah, so... my parents had a new central heating system put in, all the floor boards up job, British Gas did the work... and for some unknown reason they left all the floor boards up when the finished the job.

To this day, I don't know why they left the job, with hot exposed pipes in the floor space.  But they did... Pinky Swear.

So, Saturday morning my Dad set about putting the floor boards back down, he embroiled me in this, despite my not really knowing one end of a hammer from the other, he put the first board in place and started to put the nails into the holes they had come out of and tamp them down.

He handed me the hammer and said to put in the two nails at my end.... I placed the nail in and hammered it once.... Handing the hammer back to my Dad and we crawled forward to the next joist.

And then I felt wet on my knee... Water was merrily flowing up out of the nail hole and across the wood... warm musky water... heating system water, fresh fernox.

OMG!!!

But my brain said "hey Dad, there's water coming out this wood"... which in retrospect is one of the most spectacular brain farts I can ever imagine, they were the words my brain delivered so my mouth spoke thus.

Panic!!!!

We pull the board up... to put a finger over the hole... but we can't... the hole is in the side of the pipe... the nail had gone down, turned about 60 degree's and gone into the side of the pipe... how it managed this I'll never know, unless I buy that house strip that floor board out and dissect that joist.

So this hole in the pipe was well out of reach below the level of the joist in this cut, you could not put a finger in it... and the heating was on, this water was getting burning hot.

We wrapped towels around it, all sorts, i got scolded pretty badly by it... British Gas wouldn't come back, their home care insurance cover for this didn't cover us for our sticking a nail in the pipe, despite the argument that they pulled the bloody boards up why didn't they put them back down!!?!?!!

To this day I'll never understand why they were left like this.

But this all became my fault.

A plumber arrived about an hour later, he drained the system, cut the pipe, two compression joints and bosh fixed.

I never lived this down of course, this was over 35 years ago, but I still hear about it, and I've even written about it right here, so it plays on my mind.  Not for my ineptitude with a hammer... but for the physics of the thing, how did a nail, driven in straight as far as I could tell... How could it turn like this and stick into a pipe's side, it's lower radius of that side even from a straight above shot?

Pulling it out, the nail had a bend added a perfect bend, as though it had gone slightly into the joist and just turned.  The other nail was still straight and true...

Brain Dead Boring Boomber Bastards Next Door

Its been over a month, so I've come to terms with something... Some people are just horrid.

We'll just dial back the clock, 1945.... VE Day... All four of my grandparents were serving in the war effort, Solider, Sailor, Nurse & Land Army Girl respectively.  It was their war, their life, and I respect that immensely.

I made a video to that effect a head of VE Day.

However, with the lockdown, my wife and I, being in at risk groups didn't plan on anything for a street party out front, not least as our neighbours, as already mentioned in these pages, are quite abhorrent people breaking the rules and putting themselves and others at risk, but we also had no idea there were any such plans a foot... After all, why risk it when we and all of them are in at risk categories?!?!....

So, we sat it out, rightfully and with respect, I do spend a lot of time with my mind cast back to the world wars and I don't think any of my neighbours, unless there's some secret military historian in their ranks, can touch my knowledge of the struggle and suffering inflicted.

It was therefore with some surprise that I've heard on the grape vine how "disgusted" our direct neighbours were of our "ignoring VE Day" and "disrespecting the spirit of the day".

These fools haven't dared say this to our face, these brain dead boring boomer bastards won't face me and say a word, and you know what... that makes them pretty horrid in my book.

The Mystery FTP Clocking Machine Project

During my very first programming job I was given, late in the day, a unit which gathered user data.  It stored this data in CSV plain text and according to the manual you were to FTP into the unit and retrieve the file.

I had an FTP client, I had an FTP implementation (in Dephi) and neither could connect to the device, standard FTP commands didn't work, they just didn't work.

We could confirm it had an IP Address, see the device within the DHCP list and indeed we could ping it, so it was responding to ICMP, but no matter what the FTP client, as described in their manual, would not connect.

A TFTP client similarly could not.

We had no internet, so after going home that evening, on my own initiative I downloaded three more FTP clients and even downloaded an FTP class for the C++ IDE we could use "Borland C++ for Windows".

In the morning I tried all of these, nothing, nada, naught.

I went to get another from the pile of 30 of these we had sat with customers waiting, nada.

I plugged away at this for a week and in the end arranged for an engineer from the vendor to come see us; the chap came, he had a peek and a poke at my code, saw nothing wrong, tried this test routines, they all ran... so we were at an impasse.

Nothing we tried worked except their test routines, so I of course wanted the code to their test routines.

They were very reticent to deliver it but after a lot of prodding and some negotiation over lunch it was agreed that their own engineer could receive the code, look at it on my machine, even copy and paste a few critical parts and get us up and running with connect, disconnect and that would be it, we could then have to do all the other commands, but their engineer would sit there whilst I did at least "list".

No internet, so I took this engineer to my home address (luckily within walking distance of the office) and over my modem (yes, I'm that old) we downloaded this code to a floppy disk (yes, I'm truly that old).

We headed back to the office, set up and opened the code next to my IDE window, their code was in C, so I would have to transliterate it into Delphi later, but whilst he was present we stuck with the C code, he called his programmer and the chap confirmed it should build in Borland C for DOS.  Which I had.

Sure enough their code seemed to compile fine and it ran in debug and connected, did a list and pulled all the files off the device, deleting them after.

Their engineer did this, then he looked at the code, and he smiled, and stared at the code, then smiled at me.  Remember we've wasted my time, his time, like a week in total here.

He consulted their own operators manual, looked at the bottom of the device, smiled again, then picked up the phone.

"Is there another version of this model?"

<squiggly reply on 1998 Motorola Razor>

"Sure, sure, but is there another version?"

<Squiggly voice>

"Right, right, can you send that?"

<Loud squiggly voice>

"Yes"

<Squiggly no>

"Yes"

And he hung up.

"Sorry gentlemen, he was addressing me and my boss, but ah... it would seem you've got the wrong device".

And he arranged for them all to be collected and returned without explaining himself, he personally returned with another unit, which to me looked identical and this worked instantly.

I have never found out quite what the issue was, but the next morning 29 more of these boxes arrived and we could deliver to our downstream clients the next week.

I hate ANSI... Keyboards

What, what... who the... there are different keyboard standards?... yes, there are and one is brilliant and one is not.

Now I am not talking about any regional reworking of keys such as QWERTY versus AZERTY layouts, what I'm talking about is the size and location of THE most important key on your keyboards.

The "Enter" or "Return" key.

Lets look at a picture:

You can see here, that there are movements on certain keys, but we're really interested in the position of and size of that RETURN, in the ANSI layout it's a single height key, sure they can be longer or shorter, but generally I find this THE most annoying thing to find on any desk.

The ISO (and as we can see in this image the Japanese Standard) has a large double height key and I really like that.

The swapping of the back slash key (to the left of Z in the ISO layout) also gets on my nerves, as a programmer I use that back slash a fair bit.

The larger right shift on the ISO similarly pleases me...

So there you go... I hATe ANsI KeyBoARds!  Loath them!

The Worst (or maybe second worst) Source Control Ever

I've not made a bit deal out of this, but I like source control systems, I like git, I even like subversion, I like when folks even take the time to zip up the whole project tree and stick it on a whole other machine.  All are different source control strategies, each have their place.

What doesn't have a place in my opinion is poor implementations of this... such as... When there is no source control, that folks "remember" how the code was and can work back to where it was when things go wry.

Because inevitably they can't remember.  Solutions, subtly and satisfaction with what was present can easily be lost.  And in such situations you can only blame yourself for not having a back up of the original or yesterdays or whatever.

So it was as part of the tyrannical "lead" of one developer I came to meet the worst source control system ever, it was based on floppy disks, had no back up and was a manual process.

And it starts with an initial checkout, to a CD-R.

The CD-R was known as the "master" disc, and it contained a set of the SQL scripts to build an instance of the database, a series of sequential updates which each quarter were compacted down and made into one new "CREATE DATABASE/TABLE" thing.

Then there was an auxiliary folder with a bunch of tools which you copied to your hard drive and used.

And finally there was the source tree, you installed Microsoft Visual C++ 6 and opened the project and built the code.

You then ran a tool and put a floppy disk in, this disk was used as a swap between you and the lead developer at the end of the day, so a nightly build could be carried out (or a morning build on a Monday after a weekend) on a slightly more powerful machine.

As a developer then you had you IDE, this background tool running and you worked as you normally would.

Every time you would save in the IDE the tool saw the change in date of the source code file blatting that file onto the floppy.  The whole file, overwriting the old, not a delta, not a diffable solution, it just progressed forwards only.

You could not revert, not compare, not really do anything we take for granted in modern development.

This was a bad system.

The bad became worse when there was a delay between the save & the tool picking up, and then a floppy disk took time to write ( a lot of time ) and it was soon realized whilst it was writing the file from the HDD to the floppy it locked the file, so you couldn't write another copy of the file whilst this slow write was in progress.

As such lots of developers didn't run the tool, they would run it once at the end of the day, or just copy all the files listed as date/time changed to the floppy manually.

This floppy was then the feedback of all changes to the lead, in charge of merging the changes... Well I say merge, what happened was the mainline version was simply over written with whatever the developer handed over.  They were meant to qualify their code was coo, they were meant to run the tool which performed the copy.

So all the pieces were on the board and check-mate was one move away.

For the worst moment came on one particular Friday, a developer was toiling on tidy up duties, those little tasks you put off until the end of a day to fill time until you can go home, his task this day at 5:03pm was to correct two typo's in a file, one higher up and one lower down.

Just spelling mistakes, no need to recompile that, taking an hour, on a Friday with the pub and a takeaway calling.

So the chap performed his save, saw the light come on the disk and then did the second correction, hit save, the floppy light went off... and he turned his machine off... just dead off... pulled the floppy and dropping it into the "merge tray" on the leads desk started his weekend.

I walked into this on the Monday morning at 8am, as a very junior developer, the managers were all present, the lead was present, two senior devs were pawing over floppy disks in no discernible order.

For it turned out that the tool had started to overwrite the second save of the file, it had gotten so far through the write when the power had been pulled.  The original was lost on the developers machine for he had pulled the power... rather than shutting down.

And this source control system only went forwards, you could never ever regress.

The seniors were trying to build a delta list of each change for the last month, back to the start of the last CD-R... From floppies which had been used and reused, they had to manually inspect the changes between the file in question in the floppies.

If the copy they had was deemed to be older the disk was put aside.

If younger the file was copied into a directory to slowly try and catch the code up.

Around 10am the developer responsible wondered in, listened to the complaints, listened to everyone being exacerbated and then without a blink of irony said "Told you this wasn't source control".

Fabulous...

The worse Source Control ever?... Perforce... Hands down, Perforce.

42

I have made it... Douglas Adams would be proud.

Worst Idea in Development Ever

I'm casting back a long long way, over 15 years to be imprecise as I can, and talk about the worse idea in software development ever.... To perform a group code review once a week.

But before I can do that I need to talk about the good way to do this, code reviews should be non-intrusive for the majority of team members, they should be able to dip in and out, they should fit it into pieces of their day which are spare or otherwise dead time, and it should be use as a tool to not only review the code but introduce familiarity to other people's work & progress to everyone else.

So what was wrong 15 years ago?  Well, the important point about the good way of reviewing code was to actually be able to see the code.... When this new review process was introduced all those years ago... the code was on a machine, whilst we were all in a meeting room and the programmer stood up and verbally described the code to us.

Yes, verbally describing what took all WEEK to do, neither conveyed to us what was being done not shows us how, we were unable to help debug or sense check the logic, and it gave zero oversight into how the code was built, was it efficient for example (we'll come back to that topic in a moment).

And of course the planned one hour meeting was excruciating to be in... and only one developer got to speak in the first session.

There were 6 staff programmers and we were augmented with 6 contract programmers, the "lead" if you could call her that programmer went first... and her presentation was on the hardware to database connection.

It used a Marathon database, which I've just googled and humorously I can't find any references to that product.  And the "lead" had been using it at her prior role on Java based programming, here in C we were a little perplexed by her approach.

For she presented that from the high-speed buttons and lights on the hardware, which had to flash fast and had to be responsive to touch, she had written a system which took the impulses and inserted the values into a "Buttons" database table.  And then another on a loop which polled "SELECT * FROM LIGHTS;" and pushed the "on" or "off" states of the resulting list (from left to right) to the hardware.

Of course was immediately obvious to all but the lead, the manager and her office buddy, would not fly and the three different members of the team, all infinitely more familiar with the hardware and the C language than this lead, pointed out that it would be slow and unresponsive.   That we were on a single core machine so you couldn't just ignore that the database driver would wonder off and do it's own thing, as well as be constantly interrupted by the processing of our system, and the system itself was to be host to third party software which we could not ourselves fully control, so they might run with a tight loop starving our system and especially starving (what was then) a low priority database driver service.

All in all it sounded a REALLY bad idea.

But, she'd already done the work.  The manager had already signed off on her idea in a series of closed doors conferences with her, and her lone office buddy made it clear he was on side.

It was 3 staffers verses 3 "senior" staffers.

It was fact, this was going to happen.

Which brings us to an obvious fault in this "Code Review" no-one could actually get anything changed, we were really there to be told of the fabulous innovation from behind the green curtain.  We could not divert, advise nor simply appreciate the good, bad or ugly in this system.

So it was revision one (of twelve) was issued and immediately a real piece of content (a game) was played on the system... This game already worked on the old system we were replacing, so its behaviour was well established.  And immediately all the lights started to behave badly, they would he updating visually, we could see, from left to right... rather than all coming on together and going off together.

This was puzzling the micro-controller sending the light signals was a 32bit register, you just set the binary representation, and the micro almost immediately lit or extinguished the bulb... Why was it showing this left to right behaviour?

The three of us whom had descented said "are you going through that lights query as a list and applying it left to right?".... "No" came the reply, but she soon disappeared and came back with version 2.

Which STILL turned the lights on left to right, but subtly so, we could see it and the experienced play tested protested it was, but to the uninitiated it was just about passable.  So it went into test proper.

And they reported the same, but opposite feel to the buttons, that they lagged from right to left, and lag they did.

To her credit the "lead" didn't dismiss them and went to actually play the machine, yes she'd not played it until now... and immediately version 3 was issued.

Again, as with the lights, the lag was still there, the left hand most button was the most laggy, and that would make sense if there was a loop which was working through their being updated from right to left for the buttons and left to right for the lights.

But she insisted that there was no loop.

And we had no oversight on the code, even though we had "reviewed" it.

The next morning we walked into find her already present, version 4 had gone down to test.  The tester had put a different game on, which did a different series of light patterns and reported "It doesn't look right at all" (except he'd not been as polite) spurring the new version.

One of the more vocal of our group went to the manager and said "this going through a database is the madness, no matter what she's actually doing in the code, it can't be fast enough to feel like the old direct to hardware system, we need to remove this layer and just go direct".... but the manager didn't want to upset the "lead" so persisted with the database thing.

Release 5, 6 and 7 went down later that day, then about lunch a machine was hoisted up the fire escape stairs and into the office wheeled all the way and plonked next to the lead, she was to debug this properly.

Release 8, 9 ad 10 went only to this machine next to her and the tester was duly dragged up and into the room to sit, painfully, next to her explaining how it should plan and indeed he insisted the old system be wheeled up and plonked right next to the new borked on.

The two boxes side by side it was immediately obvious the new database driven system was really Really REALLY slow compared to the old one.

"It's the database" voices said.

"It's the loop" others called out.

"There is no loop, and the database is fast!" She persisted.

None of us from the C side bought this, and still could not see the code (code revision control is a topic for another day).

Finally, it was Friday, version 10 had remained for all of Thursday, but Friday came and something had to be done.  The engineer responsible for the board, the actual micro-controller was brought in, and he immediately ran his test routine on the board showing the lagging and we saw it being solid behave correctly and work, despite the lass having decried her board was faulty.

The hardware engineer had a view none of us got, he could see the code, he sat beside her and with us all gathered around he blinked, looked at each of us and then looked at the code, then turned to the "lead" and said "you know you can just sent the unsigned 32 bit integer directly to that register, all in one go?"

She looked at him and asked what he meant.

"Well if you want to turn it all on, send zero"... if you want to turn them all on send 4,294,967,295‬"

She blinked and looked at the code and then back at him, "I don't follow".

The hardware engineer looked at all our eager faces, three of us knew what was coming.

"Well, you don't need to loop through each boolean and bit shift them one at a time into your register sending them one at a time, you can still loop and bit shift them all in if you like, but you can sent the command once, set the lights to the value in the register once".

Three of us left the room, the manager looked dumbfounded and a little thunder struck, her office pal was notably quiet.

Version 11 came out about an hour later and the hardware engineer went to leave, popping his head into the office of the 3 of us on the C side... "Why wasn't this picked up in review?"

* Throughout you've seen me put "lead" in air quotes, this is intentional, the lass was not a lead, not as we'd describe today, she was just the loudest voice in the split office, she was furthest from the manager and had this knack of making you feel like she had ALWAYS been there and always been in charge.

I strongly believed she had been at the company for years when I started.

It wasn't until years later that I discovered she had only been in her role two weeks longer than me, two weeks in which she had moved from direct hardware peek & poke to via database.

* Version 12 : Yes you guessed it, version 12 was to remove the database from the hardware interactions completely, an abstract layer was built holding a representation of the hardware in memory and that representation was twiddled from the database side and it's representation imposed on the hardware by directly poking.

When the Manager Went Fishing

A long time ago in a work group far away there was a bunch of problems coming up in a code base whilst the manager (who had written the very code we were debugging) was up to his knees in a Scottish stream on a salmon fishing holiday....

So yeah, the code didn't work, it was a statemachine implemented in a bunch of "if" statements a smattering of switch statements and flags which were not properly mutually exclusive... so it was a statemachine in name only really.

This particular piece of code was responsible for paying money out of a machine, and as such came under scrutiny when customers started to notice that it was either paying out more than expected or the players of the machine noticed it was paying far less than expected.  A double whammy.

This problem was looked at first by a chap in the team who didn't really get along with anyone else, and he asserted he had solved the problem... I wasn't his manager, but we accepted his word on the matter and issued a release.  This turned out to be the start of a series of problems, for with the focus on this problem the test department took it upon themselves to actually test this fault to within an inch of it's life, and of course they found the problem persisted.

The wheels then came off this development train.

For the technically senior person in the department didn't get on with the chap who had looked at this problem first, they did not get on at all... not one jot.

And I ended up sitting between these two as both a debugging sounding board but physical altercation deterrent, which it's a great place to stand between coworkers who really just needed to grow up.

The debugging progressed from the mess of code into a rewrite of one function, and this started with a large discussion around a 10 foot white board (I love working on a whiteboard).

We came up with the expected behaviour, worked out the inputs we knew and then how to get that expected output to physically happen, and did so.

It worked, it would have taken that one day.... The test department were happy with their results.

The problem?  All releases had to go through review and the binaries built and packaged by one specific person... The Manager... who was still scaring salmon with a pointed stick.

We had to get on the phone to him, do you know how patchy mobile reception is in the highlands?... No... Well, "VERY" is the best way to put it.  We managed to speak to him twice, but then had to get his permission at every step, "Do the work" it's done, "build the binary" it's built, "package the update" it's compressed, "create the release notary" it's written... 

All these calls back and forth to stitch together what should have been my simply putting the package on a flash stick and handing it to the test department (because they tested everything off of our network to be as real to our operating environment as possible).

It was a nightmare... An utter break down in co-worker communications between the other two chaps, the manager not releasing the reins of control*... The slow turn around of a build and messy nature of the codebase we had to edit... not to mention that the problem was subtle and caused by a miss-understanding between the true behaviour of a physical device compared to the expected virtual representation of it within the system's view.

There, that's what happens when the manager went fishing.

* In the hope of accruing himself come modicum of job security by appearing to be a key man.