Somewhere in the mid 90’s. I was still a coder, I wrote wrappers for other peoples interfaces and I remember this as my very first defect raised on an external party.
Basically the machine would spin these diamond cutters slowly and measure their edge distortion using a very high resolution Analog to digital 24bit converter to detect the different heights and depths, then chart those on a graph. The digital values in software in those days usually came into your app via a protocol called DDE or later on via OLE. But because this was a lot of data, thousands of points along the edge, the vendor used the now ubiquitous COM pattern for speed. Almost very time your app talks to another app it’s done by COM these days, without you even knowing. But back then it was still new territory and when I found a bug that prevented us from closing off the data stream and unloading the library due to any miss-ordering of function calls I contacted the vendor and got my first external bug fix back. The problem was not fatal, but meant that if the user ever messed with the wiring of the rig itself, then closing the app would require using task manager, which was not going to be cool.
It still took about a week or two, but I remember emails sent from down in Darkest Africa up to Germany and the weird language barriers we sometimes faced. But my supreme joy when they emailed us a beta change and my problems all went away. Do you recall your first external defect?
3 Likes
I was building an internal payment processing system to replace one of our vendors. We were going to hook directly into the backend of a big banking org. All the documentation was provided via PDF and little to no real example of how to use it. There was no public forums and all docs were covered under an NDA, so you couldn’t just “ask the internet”.
But, we pushed through and made some assumptions and things sorta worked. Until one day, we found that 3 of the endpoints on their DEV system didn’t exist. We reached out the banking org and waited for the obligatory 7 business days for the cogs to turn. They didn’t have those endpoints on DEV because most people just went straight to prod with their integration 
. When we asked if they could implement those on DEV for us, they said it would happen for at least 6 months and that we could just skip that for now.
Thankfully the leadership at the company I worked at saw the problem with this and had me flush 6 mo of code down the toilet. We kept our initial payment vendor and never looked back 
2 Likes
ha ha the good old days - I have a suspicion that not just those NDA barriers, but a lot of the other ways we had to find our way in the dark are what makes these so much more memorable.
2 Likes
In 2006, I worked on a business flow automation project that also used equipment like passport scanners, barcode readers and label printers. This system was built using the Windows Workflow Foundation. When a specific event occured in the workflow, a Windows Forms program was started. This program used Internet Explorer to add ActiveX controls. This way, workers could put in the needed information from the passport scanner into the right forms.
So it was WF event spawning a windows forms program spawning internet explorer inside spawning ActiveX driver inside 
Now, you might ask, why didn’t I just use the passport scanner software directly in the Windows Forms program? That would make the system one less level complicated. Well, the passport scanner drivers had a very nasty bug: they worked only when instantiated through Internet Explorer 
It took me almost a month to admit I couldn’t understand why a normally looking DLL just didn’t produce any output from the device when linked to a Windows Forms app, but worked well when linked as an ActiveX control in Internet Explorer. I still am puzzled as to why this was the case.
1 Like
WPF and WWF were things I thankfully never had to grapple with, I see the latter is still around today.
But oh, @vitalysharovatov you have flooded back memories of apartment and single threaded ActiveX nightmares, whooo. I guess a lot of people were often never happy to write re-entrant and multi-threading optimised code back in the day. Multi-threaded code was my ace place to play at coding right from the day when dual and quad cores came out, fun times.
1 Like
WPF and WWF were things I thankfully never had to grapple with, I see the latter is still around today.
I will never stop being amused at what tech is still there. I know one company using Silverlight in their internal KMS. You have to RDP onto a machine with IE10 and consume information there
I also know a firm using Flash for their security training. They install Ruffle Flash emulator to run the training SWF. This is actually quite ridiculous
Multi-threaded code was my ace place to play at coding right from the day when dual and quad cores came out, fun times.
Yeah you can call them fun I guess
1 Like
There’s nothing like cozying up to a 5000 page PDF and trying to understand what in the world this thing is supposed to do. 
Thankfully my career has been mostly WITH the internet, but in university they taught us the “without internet” method too.
That was a cruel time @natebosscher, giving a university assignment but without the web. To be fair it would not help me much if I was in that same job today, because a lot of our work was protected by IP and still never publishes docs online.
It always used to grind me about how little info around my work there was online. I used to add a few pages into our document each time that laid out which network messages we did use and how we mapped the data into the message. This probably made customers take us more seriously and made it possible for them to spot if we have used the incorrect message types for their application too. But yeah, it used to be fun fixing bugs via email. Those were fun times.
1 Like
