You want us to make a change? We can do it, but it'll cost you... Wave a cheery goodbye to the weekend, and start the week with a hot beverage, a pastry or two and a freshly unearthed tale from the Who, Me? catacombs. "James" is the Regomised teller of today's tale, which takes us back 20 years to the financial sector. It was a time of acquisitions; his employer had just snapped up a …
This being a "Who, Me?", I was waiting for James to accidentally bring the bank's online systems crashing down, accidentally trash the accounts of a major customer, that sort of thing. Yet his simple modification worked just fine - and he performed testing on it as well.
What gives?
Who, me? Has turned into do the job your paid for, aka BAU.
I had thought that 8 would be the number of appendages and it broke over vm a bank holiday weekend or Christmas where some jurisdictions where still operational and doing file updates that effectively exceeded the appendage limit.
I suspect that the application worked on the assumption that in that file there couldn't be duplicate records for the day since it was overwritten each time, but now that assumption was no longer valid and the modification caused unintended consequences downstream.
Yes I know the saying about assumptions; as for myself I'd have some check in place anyway, just in case the same transaction was received twice on consecutive days...
I'm old enough to recall that it was fairly obvious at the time that Maxwell was dodgy, but he got off on burden of proof as unsurprisingly crooks often conceal their dodgy deeds - as was found after his death.
I wonder whatever happened to the woman his boat was named after ......
looks like dodgy behaviour runs in the family.
Must say most of the Maxwell references I recall were "bouncing Czech" type, cannot recall any Jewish references, though never keep my old eyes so cannot confirm (really should have done as there's good money in old issues but live in a small place with little storage)
Ever found the time and cash demanded by a vendor was vastly more than truly required by the actual change?
Yes, frequently.
When new in the current role we had one report outstanding that just didn't balance correctly, holding up sign-off for completion of the ERP implementation (I'd only come in towards the end to clear up the sh1t). Vendor suggested another day on site was needed and, "Could we bring another person along for the experience?"
After a full day's work they didn't resolve the problem* and then billed us for both people, travel, etc. In the mean time I'd completely rewritten the report in about 2 hours despite the fact I was unfamiliar with the data structures for that particular ERP system. I would have refused to pay but I suspect management approved it just to finalise the project.
*When I looked at the report it had VAT as price * 0.175 hard coded when the rate had recently dropped to 15%, and we were an exporter. The core table they were taking the data from had the correct VAT included as a field.
It seems there was a time when every sales rep quoted $ 100,000 for the most minor request. Usually they probably had no idea what was actually required in time and resources when trotting out that number.
I worked for a Fortune 100 company when we were discussing the purchase of a system with a vendor. Seeing deep pockets and a river of cash flowing in to their pockets, the CEO, sales people and one of their technical resources were attending.
During the talks we asked about a change and were instantly quoted the $ 100K figure and about 6 weeks to do it.
The poor innocent tech resource piped up that it was so minor a change that he could do it for about $ 5K the within a week.
I don't think the Sales Rep was thrilled. But we did buy their system, with the change
From a file format change fixed with 15 lines of VB to a change to an SAP interface which would stop the business operating (a previously unpopulated field now required populating with the same value as the field beside it) I was quoted 6 months to perform and implement the change.
This was a subsidiary of a huge energy company, the company I was working for had to submit these files daily to receive any revenue for the engineering jobs being performed, this was 10'000's per day.
This did involve me attending a corporate CAB meeting (a very large multi national) where I had to publicly humiliate the Lead SAP Dev Manager to get the change approved). It turned out she had never read the, very detailed change spec I had submitted and had merely declined the request on the basis that it was 'none core' and 'none urgent'.
In reality it would have lost £20 million pounds of revenue and would have resulted in the closure of the subsidiary business
Yeah, I just had my electric bike flash up a number of error messages (including the gem "UNDEFINED ERROR - CONTACT SUPPORT") so I emailed the dealership through their service contact form instead of trying to repeat all the gibberish over the phone.
So I bring it in and get "did you get any error messages?"
"Yes, the ones I listed in the email, there was a bunch"
[angry stare]
Turns out the service department had no access to that.
C'mon people... don't put the goddamn form up if you're going to ignore it.
"Turns out the service department had no access to that."
Stupidly common issue. I think Openreach engineers have the same problem where they don't receive all the details that are submitted by the customer. Number of times we've raised faults with OR including detailed information about what the issue is, site contacts, restrictions to access etc... only to have the OR engineer have to call us asking for that information. It was only after we got one of them to show us what they actually receive that we discovered half the information we'd submitted had been left out.
This seems to be a general issue. When I was working I'd phone in for some kind of fault in IT/Plumbing/electrics/ photocopier etc. I'd specify the location, erorr messages, symptoms. A person would arrive not knowing where the item was, what the issue was or what spare part they needed (often not even having it on the van.)
He: "Ah sorry, It needs a new hinge/seal/element. I didn't bring a spare"
Me:" I did say to them the hinge/seal/... was broken when I called".
He."They didn't tell me you'd said anything, just that the door/water boiler wasn't working.."
Me: "It's in your records that the <.....> was coming close to end of life.
He: "They don't give us those2
and so on.
About 20 years ago, I call Sears and tell them I need a warranty repair on my washing machine. I tell them the cycle selector knob ratchet has worn out and it needs a new knob fitting. Please bring a new knob.
"OK"
Two weeks later I get a confirmation call. I check they will be bringing the knob.
"The technician will determine what's needed when he gets there". I point out that is great, but that he needs to bring the knob because it is a special order part and the machine is U/S without it. They argue. I point out it is a ten dollar part retail. Bring it anyway. "OK"
The day of the repair the guy calls. I ask him if he has the knob. "What knob?" I go through the whole tale again. He pushes back. I point out that he is wasting both our time if he does not bring the knob. He yields.
He turns up, agrees the knob is needed but cannot figure out how it can be changed. So he stands there while I use his pliers to pull off the circlip and the old knob and slide the new knob into place until it clicks. Done.
Sears called six months later to ask if I wanted to extend the warranty ...
When you work for customers that when roles are reversed are going to screw you, you HAVE to screw them. That's why anything I did for lawyers, for example, costed far more than it would for another customer.... they will never do anything for you without asking a lot of money. Here they even have official prices they can't go below without being kicked out from the "Order". They even obtained that price fixing is legal, poor lads and lassies...
At Uni the lecturer* for database theory was talking about how he set the cost when pitching an ad-hoc (simple-ish) quote during a client meeting - Make an educated guess then if the IT director is present - multiply by 5, if a non-IT director is there - multiply by whatever is need to reach a healthy 5 figure number (1980's).
This is because they've tipped their hand as to how important they rate the issue.
*He was an IBM mainframe DB consultant in between lectures.
Yup, it's the financial variant of Mr Scott's Law (aka the Scotty Principle) of estimating how long it will take (which of course also needs applying in its pure form)...
I was implementing a new service bureau for a european bank out in Romania (worked out there for about 4 months)
Long story which I won't go into though it was internal service bureau competing against another internal service bureau but it was more dynamic to changes and would charge 10% of the cost of the other one and ran with with 15 staff total rather than a couple of hundred, I digress....
I was interrupted with what I was doing and was asked to join a conference call between them and a vendor trying to upsell something in the product as a party with no vested interest with either of them.
The vendor was saying that this new component was going to cost €100,000 and was trying to get the bank to foot the development bill even though the vendor was trying to sell it to them. I said, I could implement what the vendor was trying to sell for free with the current software and about an hour of time so didn't need it at all.
Was fun listening to the vendor get angrier and angrier as they realised their attempt to get the bank to pay for the dev (which they would then sell on to other customers) evaporate before their eyes and that the rest of the value add had evaporated with it.
Fun times!
"Ever found the time and cash demanded by a vendor was vastly more than truly required by the actual change?"
I had a client who managed to do that all on his own.
I did occasional support work for him but the vendor still required a support contract with themselves. To enforce this they had some sort of lock on the system which involved periodically running something - I'm not sure if they logged in remotely, sent him a file to run or just gave him instructions to do it himself. I kept well clear of that. What they didn't do was provide actual updates to the S/W so in that respect they weren't providing anything in particular, just occasional problem solving.
My remit had been a bit wider as general Unix and DB admin stuff. I'd very quickly come to my own view of their S/W and, in fact, one of the things I was doing was writing bits & pieces round it to do stuff the client wanted. Eventually he realised that their support contract was providing him with nothing and he worked out the coding of the lock file that had to be changed every 6 months or so, ended the contract and updated the lock himself.
It depends. If the software license explicitly states that it is only valid in combination with a service contract, then they are using the software unlicensed - which is also called "piracy".
If the lock file stuff was only a technical measure to enforce the use of the service contract, but not part of the software license itself, then (at least here in Germany) the software is damaged, as it cannot be used for its purpose. Reverse engineering the mechanism be analyzing the lock file and without decompiling the software is not illegal.
AFAIK he'd paid for the package. The support contract was being sold on as an extra.
I'm quite used to the situation where a package is sold and a support contract is optional but selling a support contract and trying to lock the customer out if they don't keep paying is taking the piss in my view.
There were some interesting features to the S/W:
- It was supposed to be based on Informix. Some Informix tools were supplied for reporting but it wasn't written in it for reasons which became apparent.
- They included some files with .sql suffixes which were supposed to be the DDL to set up the database. They weren't even SQL although possibly their S/W would read them to add some tables. They didn't comprise the full set.
- They provided a bcheck* program to check the database. The supplied Informix package also provided bcheck. The bchecks were different. Either would complain there were "errors" if the alternative bcheck had been run first. The DB was OK, it was just that the two products were setting a flag or label differently.
- There were the usual Informix system tables which included indexes. It became clear that the system they provided couldn't have run efficiently with just the indexes listed. When I needed extras for reports I was writing I investigated further with bcheck and discovered that there were indeed more indexes, they just hadn't told Informix's sysindexes about them. Clearly they'd set up the database with some other tools and copied in the Informix system catalogs from a rather less fully featured database to keep the Informix tools more or less happy. I hacked sysindexes with SQL to add in some of the missing entries.
I'm pretty sure that what they'd done was use a C-ISAM package** of which there were a few - possibly even a FOSS one - to write the software, marketed it as being based on Informix and sold some Informix tools along with it although they didn't have a chance of working as well as they might. On the whole I think it balanced out as six of one, half a dozen of the other.
I've often wondered if it was the same crowd who flogged a warehousing system to my ex employers about the time I was being eased out. Some time previously we'd proposed adding warehousing to the existing stock and SOP system - it only needed a couple of extra tables to describe the racking an the additional screens to support it. That had been turned down. Some crowd claimed to be offering an Informix-based system running on VMS sold them a free-standing warehouse system. I knew very well that there wasn't Informix on VMS; we'd been one of the guinea pigs when such a thing was attempted and abandoned. They countered that by claiming to have the database source code It must have been the same thing - an application built on a C-ISAM package. At least I was out of it before I had to cope with trying to keep two separate systems giving their views on stock levels.
* bcheck was a diagnostic for the b-tree indexes.
** Informix Standard Engine, even in its pre-SQL version was based on a C-ISAM package of their own (AFAIK) devising.
When I was running the Technical Manuals department of a large electrical manufacturing company, we had a desktop publishing system installed from a well known photocopier manufacturer. It had a password to change any of its settings, which I was duly authorised to use. However, said password expired on the first of January of the following year, so I couldn't do my usual maintenance. The vendor wanted an awful lot of cash to supply us with a new password, one that wouldn't expire next year. I then realised that the system took its date information from the Internet, using Windows Date, so I disabled the internet connection and set the time and date back to the previous year, at which point the old password became valid again. After making the necessary changes, I simply reset the time and date to the correct values, reconnected the internet connection, and carried on using the newly modified system. Never did pay for that shiny new permanent password, kept going back to the old one as required.
We used to use McAfee Encyption software for laptops a few years ago. If there was a problem with the laptop, you could boot from USB/CD with tools to access the data on the lappy. You have to have some sort of token from the server, and also Code of the Day - 4 digit PIN that changed daily.
The chap in charge of the server was a bit of a git - you had to ask him for the COTD and he would take ages to get back to you as he "was too busy"
Managed to get one done and wrote it down. Next laptop - into the BIOS, changed date to previous date - same code, job done!
Had similar years ago with a server app used by a customer. Admin functions needed a COTD and the suppliers support department were a pain to contact (and only 9-5, so no use when doing work out of hours).
Got fed up with it so started making a note of each COTD we received and the date we received it. Popped them into Excel and after a bit of guess work to find the starting value, I'd figured out the formula they were using to produce the COTD (essentially a simple starting value +/x date) and could populate the dates for the rest of the year. Annual starting value wasn't as straight forward, so think I only called them again at the start of the following year to get a couple of codes, and work out the new list (and with two starting values, also work out where those start values came from).
Reminds me of the time I bought a new PC with a free year of Norton AV.
The year expired, I switched to a different AV, tried to uninstall Norton. Or even disable it.
"Please log in to access the admin screen ..."
"You can't log in as your subscription is expired. Click here to renew your subscription..."
The product as installed offered no way to remove it after your subscription had expired, without paying for renewal.
They did provide an "uninstall tool" as a separate download. But it was pretty well hidden on their website, took quite a bit of googling to find it.
I'm not an IT person but I did have to act as translator between IT people and other staff in the education sector in the same time frame as James and his bank.
A college Web site had a course listing with days/times/subjects/costs etc. The listing was produced from a spreadsheet on the shared drive via Mavis with a copy of Dreamweaver with some templates. The spreadsheet was updated by the managers for each department, and it was the Single Source of Truth for both the Web site and the printed brochure, the latter merged into a QuarkXPress template.
Time to get professional: A Web design company made a presentation to marketing manager about a database driven Web application and something was bought on a subscription basis.
Result: Mavis still produced the printed brochure from the Single Source of Truth spreadsheet, but also now had to retype the information into the poky little form on the admin page of the Web application. So we were paying monthly for a system that generated more work with the possibility of errors.
These days: most have got back to something sane (a Single Source of Truth, but these days coming from a business planning application - another source of pain).
The £100,000 is either "wanker tax" because the client has previously done something to seriously piss off the supplier, or it's a ridiculously high quote to indicate that they really don't want the bother of making that change.
I'd hazard a guess that the software supplier in this case had hired someone to write the application in question, who had subsequently left, or been made redundant, because of a cost-saving exercise (of the sort that always costs more in the long run, but makes that quarter's books look good). The application in question had then been left unmaintained, and with nobody knowing anything about how it works, or what it does. They didn't want to face the time and expense of hiring someone new, and training them up, to make a trivial change. Factor in recruitment and training costs, and contractor's rates (it won't be a permanent position) and a reasonable profit for the supplier's company, and they may well think £100K is a fair price. Sadly, in my experience, this sort of mismanagement is all too common in the industry.
I was once given the opportunity to excel by supporting a “tiny little unimportant system” used by only one team. So I innocently contacted the current outsourced support, a lovely old gent who was a joy to work with. Alas he was heavily involved in updating his personal status to “dead”, hence my new opportunity.
To start my journey I tried to find a new outsourced supplier, then I hit a brick wall. There wasn’t anyone, anywhere who offered support in this programming language. I had found a genuine dead language, invented by a tiny little company which had died a decade ago. I asked six different employment vampires to find anybody who had it on their CV, ten grand to whoever found me a live body willing to help us. Three of them found a likely lad, alas he was our current guy.
So he sent me all his notes and the very well used language manual before politely leaving the house.
I supported the software for five more years, putting it into the risk register each year at the nuclear risk and result level. It cost the company no money and only resulted in a 20% increase in my tendency to kill users who asked stupid questions.
One of the last bugs I fixed before I left a previous company was deep in the bowels of the Qt printing code.
Most printing issues can be reproduced using a virtual, PDF printer driver. This one could only be reproduced using a large format, physical printer. Each change/test required sending a print to said printer and examining the physical output. I managed to burn through a roll and a half of the printer paper (at £80/roll) over the course of three weeks of investigation. Management were horrified but I pointed out the cost was insignificant compared to my time.
In the end, the problem was a bug in the HP plotter driver. As far as I could tell, the plotter driver tiled the output and was running out of memory during the tiling process. The solution was to halve the size of the tile.
Thus, after three weeks of solid effort, the sum total of my efforts were something like:
tileSize = (previous code to calculate tile size) / 2;
That's right - three weeks of concerted effort for two characters!
So often I get asked "How long will it take to fix this issue?"
They really don't appreciate that the answer is almost as often "probably about 5 minutes, but it might take a couple of weeks to figure out where to do the fix." (or an hour, or a month, etc depending on my current familiarity with and the nature of the system in question)
My stock answer to that these days is "it's a ball of string" - i.e. come back and ask me again in a few hours once I've had a chance to do some first pass analysis of the debug logs... Fortunately, the people I work with are a) intelligent enough to know full well that sometimes that's the only type of answer that can be given for that question, and b) know me well enough to know I don't give an answer like that unless I genuinely don't yet have a better one for them.
Inherited a codebase at a previous company which had been done by a well known outsourcing company in Asia. It was the WORST code I had ever seen in my 20+ years of experience and, believe me, I've seen (and written) some stinkers. It had every anti-pattern and bad practice you can think of and a few new ones to boot.
Turns out the developers were penalised if they didn't write at least 200 lines of code per day. Their motivation was not to write good code but to write 200 lines of code. They weren't paid on quality but on volume. We brought the development inhouse where our developer's motivations were the exact opposite.
Never get mercenaries to defend your castle.
I know someone who worked for a large multi national company, and about 40 years ago, one of their key metrics was defects per loc.
The counting was simplistic number of "if" "select" "case" and semicolons.
He said that was stupid - (complex code takes longer to write etc).
He proved it, by inserting lots of dead code such as if ( 0 ==1) {... } and wrote lots of code in the {}, and lots of I = 0; repeatedly.
Because there was so much dead code, their algorithm for defects per line of code, came out as negative negative defects.
When the chart was displayed to management - they saw how stupid the metric was.
A couple of years later the developers were asked to break the work into 'tasks' of 1-2 weeks duration, and they started to track these.
They found it more accurate when they had to size the work if someone else had to do it (if I do it, it will take a week. If Fred does it it will take 2 weeks - we'll say 2 weeks.)
For each task they had to identify dependencies and so there was some real project management, and reordering of work.
Getting what you ask for (or at least what you measure). Always a joy with KPIs.
The other joy is when it comes time to devise the next set of KPIs:
"We have to have KPIs otherwise how will we know if we're doing well!"
"So, what constitutes doing well then?"
"Erm, doing stuff on time or doing more stuff, no wait doing less stuff... erm... well it depends on what we're doing..."
"Yes it does doesn't it, also, half of that is target-setting, not performance indication..."
"..."
Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
Restated and generalised by Marilyn Strathern as:
When a measure becomes a target, it ceases to be a good measure.
Oh KPIs, how I don't miss you... The least enjoyable times in my career so far (experiencing redundancies/company insolvencies included) have been trying to work within the stifling confines of the KPI process, particularly when being managed by people who really do believe that KPIs are A Good Thing and expect the minions under them to be equally excited about the chance to spend the next year chasing dubiously set targets, some of which might even have some direct relevance to the work you actually need to be doing that year, but most of which are there just to satisfy the requirement that you have at least one of each type of KPI.
Ugh. Doubly so when they're individual performance metrics. For instance, some of mine:
Didn't let any of my training go late
Didn't cause a major incident with the business
Didn't have any notable complaints against me
Didn't have a safety incident
Didn't have a high absentee rate
etc. Looking carefully at the list, I could get an Exceeds Expectations rating simply by showing up and making sure my training got done - without doing any actual work. Hmm. (My manager would clearly not allow that, and shouldn't.)
And then there's the requirement that we put in a personal development goal, and track it, and complete it, and we get dinged if it's not done on time. But what it is is entirely up to the individual employee...
Spaghetti code and lines-of-code = pay. Sounds like an outsourcing company I worked with. We used them for software development AND writing test cases. Their metric was number of test cases per time period. They actually wrote a system that automatically generated unique test cases. As an example, instead of opening the app and clicking on options 1 through 100 in a loop, they wrote 100 test cases, all the same except for which option to click. 100x increase in productivity, so they asked for (and almost received) extra pay. Turns out the guys writing the checks knew nothing about code but just saw the spreadsheet metric and were taken in.
Needless to say the guys who pointed that out were not very popular with the contracting company.
James is a good egg and all that, and a shining example of engineering as a calling rather than a job.
That being said, given his imminent departure, and the principle of "if you touch it, you own it"**, it might have been smarter to hum and haw and gently pull away from doing anything about the problem.
Or, in a more mercenary fashion, to tip the wink to someone to underbid the original vendor and cut James in for a finder's fee, once he had departed the bank. It's nasty, but that's business, especially in the cozy confines of the UK.
** Or if you prefer, "No good deed goes unpunished".
This is a complete reversal situation in some ways, but at my company we had an ampoule filler - you know, those glass cylinders with a snap-off top for medicines.
It was fairly ancient compared to what was available at the time, and it was very unreliable. The turret was mounted on a brass bush, and the bush was so worn that the turret rocked as it rotated, and that resulted in poor seals from the gas flame jets. The department engineer used to regularly have it down for a week to 'insert shims' to reduce the movement.
I won't go into (too much) detail here, but me - as a chemist, and technical account manager responsible for process development - got roped into being a business account manager by virtue of the existing BAM being promoted, and the incumbent BAM not being available for 12 months because of her replacement being on maternity leave. I didn't want to do it, since it involved getting involved in finance, which I had no experience with. But my company relished such situations of having people do multiple jobs they had no training in.
Anyway, on my first visit to a customer as BAM, I was met with outright aggression. It turned out we were a year behind on orders, and it was all down to that bloody machine being down half of the time. I promised I would get it sorted, and I was so sincere that I won them over. They even offered to write off all outstanding orders if I could resolve the issues.
When I got back, I kicked up a stink. Frankly, every single person who had ever allowed it to get to this stage should have been sacked because of incompetence (and that included my immediate manager, the one above him, the department manager where the machine was located, and that bloody engineer). But I got them to accept the machine needed fixing properly, and 'inserting shims' was not the way to go about it. However, it turned out that there was absolutely no way in hell they were going to get the manufacturer in to do a proper service because it 'would cost too much', so once again it fell to the department engineer.
I expected a new bush to be made from the CAD drawings. Except we didn't have CAD drawings (they'd been lost), and buying a new set from the manufacturer would also be 'too expensive'.
And guess what? The engineer removed the old bush - which had at least 15 years' of wear and tear, and was the cause of all the issues - sent it to the local 'fab shop' (aka a local engineering firm he had links with) and they knocked up a copy of the old worn bush!
I just put my head in my hands when I found out. He hadn't even considered that unless we knew the precise dimensions, any duplicate would also just duplicate the errors.
Well, it gets even better in some respects, though in a digressionary way.
The company involved DID write off the outstanding orders.
We made some headway with new orders, but the deal with the company was unilaterally terminated at our end just over 12 months later by the manager who had secured it in the first place by undercutting so much we were manufacturing at a virtual loss when you added the problems on top. The main product was sticky, and the machine didn't like it at the best of times, and manufacturing delays had knock-on effects for other customers' jobs, so those were in arrears, too.
Something I can't get across in anything under several thousand words is the internal politics that you had to fight through at every step of the way. People objected to everything, they all wanted their own little empires and aspired to higher management, and the company operated on a policy of why keep things simple when they could be much more complex? The complexity stemmed from trying to appease everyone, instead of applying logic telling them to do the job.
The decision to terminate was forced from higher up, as the factory was directed to prioritise 'internal' customers over third parties (my company had various 'divisions' as well as providing contract manufacture).
Fortunately, I was not BAM by that time and didn't have to face the customer.
The machine never was serviced properly, and for all I know it is probably still being used now some 20 years later, with more shim than bush under that turret.
It stank.
Indeed.
For further information, that machine and the staff who operated it was a nightmare. One of its party pieces was 'sunken tops' - where the intended hemispherical seal on the top sank down to produce a knobbly flattened surface. It was partly down to age, partly due to movement of that turret, and partly due to staff not being able to set it up properly.
Bearing in mind the ampoule contents had to be sterile, so a complete seal was essential, my company didn't want to write-off entire batches, so it convinced customers they were still good seals (even though they looked awful) and pushed them into accepting them.
And the test for integrity?
Poke a Biro into the depression, and if it didn't penetrate then the seal was 'good'.
Honestly, I am not making that up.
In a separate story for another contract we had, I had travelled a couple of hundred miles to visit a customer one day (this was in my primary role as a technical manager), and there was a vague plan to visit another who was a hundred miles elsewhere in the afternoon if I had time.
As it turned out, I didn't. So I phoned them to let them know, and they were unaccountably furious when we had had a fantastic relationship to that point.
It turned out that while I was on the road, some prat in the QC department had phoned them up and told them we couldn't make their product after all without even mentioning it to me at any stage previously!
This customer was relying on us. Absolutely relying on us. I can't say why, but let's say it had very strong implications at the time for national political reasons.
You can imagine how embarrassing it would have been trying to deal with that, when the person who had made that call had now gone home (I arrived around 7pm that evening at their site).
This was what I had to work with. All the time.
S'funny I posted about a similar thing a few days ago. My late dad working for a firm that wouldn't replace ancient sewing machines even though the cost of letting them fall over all the time was far higher than the cost of replacement. You can blame cash flow for some incidences of this, I guess. But mostly it's bosses who see a headline figure, (£2,000 say) and not the cost of not replacing (maybe £4,000 over the year).
https://forums.theregister.com/forum/all/2021/09/08/patch_now_why_enterprise_exploits/
NYC subway breakdown blamed on ‘power off’ button being hit
https://apnews.com/article/kathy-hochul-business-new-york-new-york-city-power-outages-bc73377e1bb1cd572dd8e67cf31fac2f
Anybody want to confess?
TLDR: The mollyguard that it was supposed to have was missing.
I was helping a small (4 employee) company with upgrading from DOS to Windows.
Part of this was moving client data from a weird bespoke database application to a real database. Access, if I remember correctly.
The DOS jobbie appeared to be some sort of compiled BASIC, and the data files were written out in an utterly incomprehensible format (including strings written backwards).
They enquired about buying an add on module to export the data in a regular format like CSV in order to import it into the Windows software.
Perhaps seeing the writing on the wall, the guy, some elderly gent near Brighton, quoted a four figure sum and told them it would take several weeks "to test".
I wasn't able to take a copy of the software, it was keyed to their PC. So they loaned me the entire machine for a weekend.
I fired up that machine and told it to print a full report. Then I fired up a PC and a terminal and set it to wait for an Xmodem download.
In between the two? My trusty Acorn A5000, pretending to be a printer, receiving the data from the DOS database and building up an image of the report output in memory. When it received a page feed, it would rummage through the data in memory, extract all the relevant information, reformat it as CSV data, and append it to another memory block. When that other block (a circular buffer) exceeded 256 bytes, an Xmodem block would be transmitted to the PC.
So this little bit of BBC BASIC was reading in data from the DOS program, translating it to CSV in real time, and pushing it to the Windows terminal.
The database loaded the CSV file, and everything worked correctly first time.
Sometimes people charge such stupid prices for doing something relatively simple that the only option is to find a nerd to think of an alternative method.
Was this success accompanied by a three figure sum? Or was the client willing to pony up four figures, or even more, to avoid the "several" week delay? And apropos of that, what did the testing entail? After all, you have to make sure you have the data in the right place.
Tossing the data to a LaserJet and manually going through the printouts and comparing what was on the page with what was in the database, crossing everything out with pencil once checked.
As for pay, nothing. Not even a warm hamburger. A situation that was "complicated" (fucking gaslighting control freak that treated my mother like shit) that helped to make me the cynical fart I am now. Let's just say "the opportunity to leave the country arose and we didn't look back" and leave it at that.
I once changed an IF statement for $500,000. In the machine code, it amounted to a single bit change. OK, it was code used in a flight control computer for a fighter bomber, so a wee little bit of Systems Engineering, Test and Validation, QA and CM were also required...
In a similar vein, I once earned a tidy sum for making some arrays in a Pascal program bigger. And for carefully re-arranging the code overlays (RSX-11M!!) so the memory stayed within bounds. The client, a plastics manufacturer, even paid my hourly rate for travel time of 6 hours total. On site time was slightly less than that.
A good day.
While working for a government deprtment I was asked about an application being used by police forces to record sick absences. The system had stopped accepting new records and the supplier had asked for several thousand pounds and several weeks to fix it. On learning that it was an Access database I asked if the system stopped working after 32767 records had been added. The guy asking me was gobsmacked that I could be so specific and correct! The autonumber primark key column had been defined as a short integer and had hit the max limit. Changing this to a long integer took 5 seconds and the system started working again.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
