What’s the most asinine technical requirement you’ve had to work into a design? | Hacker News Reader

What’s the most asinine technical requirement you’ve had to work into a design?

prokopetz.tumblr.com

87 pointspavel_lishin76 comments

Back in the days of modems I worked at a company that was selling video games over the internet. The owner was a former IBM middle manager that thought she knew a lot more about technology then she actually did - not uncommon. One day she decides that she wants the game downloads to work one byte at a time so that people could be absolutely sure they received them and could not complain they had been cut off and didn’t receive the complete file (Was very common for people to download the games then dispute the transaction with the credit card company, they got to keep the game and we always lost the dispute). We tried to explain that sending the file a byte at a time, depending on the protocols involved, would turn a one megabyte file into a 93 megabyte transmission that would take more then a day to complete as each byte was transmitted and acknowledged but she could not be swayed. So instead we made the system call for each byte and thanked god for John Nagle.

https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm

This is an interesting example of a business idea resulting in an asinine technical solution, but thinking about the actual business problem, it seems like you would want to transmit an encrypted blob to the customer, and then transmit the decryption key at the end using your "very reliable" communication method. The decryption key isn't "usable" until the entire thing is received, which means the entire game isn't usable until then either. (I don't think this actually solves the real he-said-she-said problem, but I think it would appease the PM in charge.)

There has probably been a lot of thought into problems like this, and it would be interesting to hear any real solutions used.

My addition would be to pre-calculate a checksum for the encrypted blob, and only send the decryption key after receiving the checksum from the downloader.

You would then have a clear audit history showing that the user had downloaded the file completely, though you still have the possibility that they would claim the encryption key wasn't sent, or similar.

I also wonder what the impact of (presumably) having to encrypt the file for each downloader individually.

The trick is that it’s not really a technical problem, the people receive the download just fine, they just don’t like the game, or get tired of it after a few minutes, or never had any intention of paying in the first place - so they do a charge back via their credit card issuer. That is successful just about all the time unless the cardholder and merchant have the same bank, or it is an oil/gas transaction (petroleum companies have some special arrangement where the card has to be reported stolen in order for a chargeback to be successful). I always thought that giving away a couple level demo of the game was the best way to weed out the first two categories of people. I don’t think there is much you can really do about the third. As much as it gets abused I’m glad the chargeback system exists, I’ve needed it a few times.

All praise @animats

Database IDs should be considered an implementation detail. It's better to assign a randomly-generated identifier for public-facing APIs for exactly this reason.

Exposing auto incrementing IDs also lets your partners and competitors both see how big your tables are and make estimates at your growth rate.

Always assign random identifiers.

Or you just hit your auto-incrementer at an exponential rate. #growthhacking

The way I heard it the "company" was Germany during WWII, the "tables" were tanks, and the allies could estimate the number they had produced because of incrementing ids.

Yes, but amazingly, Hitler had countered this strategy when founding the NSDAP to make the party appear to be larger than it was. The membership numbering started from 501 iso 1. He was number 555.

Remember web counters for visits? My company started them always at 1000 :-D

Some accounting firms actually take this into account when you're sending bills.

In my country bills must have an auto incremented bill number. You cannot issue bill #100 without having 99 bills before.

I know one auditing firm that used those ids to spot fraud: some managers started their own firm and started giving contracts to that firm.

The auditors spotted something was going on because the bills have a very low number, and they incremented by 1 or 2 every month - a sign I am your only customer.

Which country is that?

It’s definitely true in Holland. The only resolution you’re allowed to shard by is yearly, so 2019-1, 2019-2,.. , 2020-1. Or just all out increment forever.

I assume it makes it harder to hide invoices during an audit.

How do companies with hundreds of sales points deal with that? Is a centralized invoicing system required by law? I find it hard to believe that multiple numbering sequences are not allowed.

I'm pretty sure the grandparent is wrong. You are allowed to have multiple sequences, for example one per store. Maybe even one per client.

> een opeenvolgend nummer

- https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/...

Translation: "a sequential number."

Exceptions are explicitly and exhaustively listed here: https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/... , e.g. the requirements for <€100 are relaxed and don't include the number. Note also that this is not for B2C receipts; this is for B2B invoices.

I'll admit the Dutch IRS site is lacking in info. I remember this information from reading the IRS handbook (ugh) back when I was a sole trader there, and extensive conversations with my accountant on the matter.

However, I would bet good money that a separate invoice category per client is not OK. Very interested to be proven wrong.

Denmark as well. It is so audit can see that there is an item missing between item #54 and #56.

It's not bullet proof, but it does help auditors.

That's interesting. In Poland invoices also have to contain an auto-incrementing component (so you can't backdate something and slip it in, or post an invoice to a client but skip it when reporting taxes). However each company can design multiple "series" of invoices, for example per-client (e.g. 1/2019/MSFT, 1/2019/AAPL) or per type of services (1/2019/IT, 1/2019/Design) or office location (1/2019/CityA, 1/2019/CityB) or basically whatever. The year is optional, numbers could increment indefinitely, but it's convenient to reset the counter each year (or each month for large companies).

Same for Spain.

You are not necessarily right. It's because of limited knowledge of structure and architecture. Eg. developer giving someone `create table` statement (without table data). In MySQL engine this statement by default contains last auto incremented id. So someone executing that statement and then inserting record could end with id equals to 12345 even though it's very first record.

I just use a single sequence for the whole database. It's much less information leakage and you never have to worry about confusing thing 5 with otherthing 5 in a query.

I had a project with a client who didn't like databases. He demanded that all data was to be written in plain text files.

I then spent a couple weeks writing code that would allow me to query those files for records with specific IDs and cross-reference those IDs with information on other files.

You know, just like a database does. Only slower, probably buggier, and with no real ACID compliance. Whoever came after me must have thought that I was an idiot.

Sounds like something that'd be part of Plan 9

You reminded me of a project I came into like that, a long time ago.

Reason? One of the directors wanted to be able to install this web app on his laptap, but it already had to much crap on there, and he didn't want to install a database. So we had to use files. No, this web app was going to be installed on a proper web server. He just might want it on his laptop too. You know, just in case.

Weird thing was, later we had to do various indexing stuff .... so we just put a database in. The files were still the source of truth, the database was more like a caching layer.

Isnt there some microsoft ODBC provider that can execute sql-like query against text or csv file? I faintly remember something like that.

Your comment made me look into it. I think you mean the "Microsoft Text Driver", included in the now-deprecated Microsoft Jet Database Engine. I found some references to it going as back as 2003, so there's a good chance that it was already around at the time of my project.

I'll keep your comment in mind for the next time one of those threads titled "what would you tell your past self?" pops up.

I had to write software that sent updates out to retail outlets. I specified they should use internal modems capable of at least 9600 baud.

Customer replies "Your salesman said we only needed 2400 baud modems" - and buys EXTERNAL 2400 baud modems to save £5 per modem. (Different budget to the phone line you see).

Of course now you had to rely on the retail staff to have left the modem plugged in and turned on. (Which they often didn't).

And the transmission time increased so much that we had to build in additional compression (and complexity) to try and ensure it finished in time.

Why employ technical experts if you're just going to ignore them?

This sounds kind of like when Steve Jobs threw a fit when he couldn't be employee #1:

> An early showdown came over employee badge numbers. Scott assigned #1 to Wozniak and #2 to Jobs. Not surprisingly, Jobs demanded to be #1. “I wouldn’t let him have it, because that would stoke his ego even more,” said Scott. Jobs threw a tantrum, even cried. Finally, he proposed a solution. He would have badge #0. Scott relented, at least for the purpose of the badge, but the Bank of America required a positive integer for its payroll system and Jobs’s remained #2.

(From Steve Jobs.)

I really cannot understand this kind of behavior coming from a smart, adult person.

Crying over a badge number? Doesn't it reveal a deeply troubled personality?

Or am I just too naive and Jobs actually understood the importance of being first?

Steve dude

Few “great men” are psychologically well-adjusted. Their poor adjustment is what creates the friction that causes them to reshape their surroundings.

Here's to the crazy ones, the square pegs in the round hole...

I think you can be an unbearable character and a sucessful boss at the same time — it is certainly nit unheard of.

I remember we had a school headmaster who did a great job in taking the school in a new direction, but he was a sexist, choleric maniac with little self control and a lot of irrational behaviour. These thinga don’t necessarily exclude each other

Humans are made up of many loosely independent traits. You can be a genius and also a pissbaby; in fact, many successful geniuses are, since always wanting to have your way is beneficial if your way is usually correct.

I'd counter with a paraphrased line from Rick and Morty (yes, I know...) --

When you're an asshole it doesn't matter if you're right or wrong, because people don't want to give you the satisfaction of admitting you're right.

Sounds to me like an inferiority complex of some description. But that's just my layman interpretation, I'm not a psychologist.

At that age wasn't he barely an adult anyway?

Seems he was right. People undeservedly think Jobs was "the inventor of the computer and the phone", and little touches of bullshit like that went a great deal to form that image.

More than once I've had to engineer a bug into new code to make it "bug-compatible" with old clients.

https://www.xkcd.com/1172/

I worked on a billing system for a government service in the USA. The system served both government clients and non-government ones. The government ones were tracked as 'federal' and others 'non-federal'. There were mostly minor differences between how the two were handled, but one of those distinctions was in what type of transactions the different category of customer was allowed to use.

From the customers perspective, the only real difference when it came to reading the billing information they received was that federal agencies received a bill that said 'federal' and others received a bill that said 'non-federal'. No big deal, right? Well, not to most agencies. But the US government works pretty closely with, and extends government-style permissions to, various native American tribal authorities. Native American tribes... do not like to be considered to be part of the US government. At all.

It's entirely understandable, but we had to make a bunch of modifications because they wanted to retain the ability to run 'federal agency' style transactions, but wanted their bills to say 'non-federal'. It actually caused quite a lot of drama, but most of it was isolated to the political side of the agency (software changes are not free, after all, so they tried to be diplomatic and begged the tribes lodging the complaint to just ignore the word 'federal' on the monthly bills they received, but they would not budge and demanded it be changed ASAP) luckily. As software lead on the project I did get to hear about some of the firestorm secondhand when working with management to figure out exactly how we were going to change things. The 'federal' designation was a boolean in the database, used both by us in the billing system to determined what kind of processing to do (it impacted amount charged too, with federal customers getting a small discount) and the frontend of the system to kick out attempts to use transaction types not supported for non-federal agencies. So they couldn't just flip the bit and make them non-federal or it would cause even more chaos. It's been a long time ago now, but I believe we ended up special-casing it so that the report templates for the non-federal bills were applied in cases where the agencies were on a hard-coded list of 'federal but non-federal' agencies. All over text maybe 2 people even ever saw.

This would probably be an exciting "Ask HN" post subject. I love learning from others experience handling customer requirements.

I worked in a company that have been using a sql database for a really long time, like +20 years.

In the original design of the database, they though it would be a great idea to use negative ID for system use (on the same tables that are being used for user data). No foreign key whatsoever.

Forward 2018 when we have to build a system that have to work with this widedly used database (it's for a french ERP). Because there is no index or foreign keys the queries are really slow which make our interface slow. Because the tables are accessible but belong to the ERP we cannot modify them because the ERP is under a licence so we don't have access to remodeling of the tables or how the data is processed before being saved in the database.

So to work around the problem we had to create duplicates of the tables with proper index and foreign keys and start a cron job every minute to read from the original tables and fill the datas into our tables ...

Mind boggling .. The software is being sold to a lot of companies which is kind of sad.

Not that this dismisses the ridiculousness of the original design, but couldn’t you just use materialized views as a workaround?

Yes, that would make it easier. However, they still would have to be triggered by a cronjob or something like that.

Top quality software isnt as valuable as we like to think.

Yeah until it comes back and bites you in the a$$. Even toy projects take longer than supposed because we devs think it's a one time thing only. My experience is most of the time software lasts much longer than expected.

Not for customers. What we developers call quality is usually readability and maintainability. But that doesn't affect customers one bit if the software solves the problem it is supposed to.

Of course it affects price and development speed which may in the long run sink the company in the marketplace, like what happend to e.g. QuarkXPress.

Whatever happened to QuarkXPress? I remember seeing it all over the place and it was the de facto standard in desktop publishing for quite awhile in the 90s, but then it just sorta... disappeared. Do you know of anywhere I could find a good technically-aimed history or breakdown of what went wrong?

Not sure - rumor is they outsourced all development to India to save money. But the program became very crash-pone, and they became extremely slow to add new features. And then InDesign came on the market, iterated quickly, and ate Quarks lunch.

Even 20 years ago not having any FK's is problematic I would have never done that as a green developer 35 years ago.

Just curious: was there some problem caused by the negativity of the IDs? Or, was the problem mostly having to do with the lack of indexes? Not sure I understand the problem.

The problem for me was that, they used negative ID to store unrelated data from the table intent. It's like having a kind of "hidden world" within your tables.

There is a lot of topics discussing the use of negative ID when the ID store the same datas all the way from negative to positive.

But storing unrelated datas - data reserved to the system for the developper - on the negative IDs of table ... to "save space" ? That for me is bad database design and a problem.

Solution: Reserve cool user ids and sell them yourself later if your service becomes popular?

"ID Squatting"

I remember people were selling premium UIDs in ICQ. Also, low, 5-digit UIDs could be sold for single hundreds dollars. A novel way to indicate you were an ICQ veteran.

Similar thing has happened on Slashdot - the shorter the ID, the higher prestige

I recall when I worked on Billing for Telecom Gold (Uk Dialcom) one account manger in charge of online databases wanted our billing system to assign the revenue from the data traffic during a data base session to his LOB.

We told him NO - though we could have done it I suppose, the billing system capable of incredible granularity - unlike BUCK$ eh Vint

In the early 2000s I had to interface with a credit card authorization and settlement system for a major credit card. I opened a socket, sent a perfectly formatted transmission, and got back gobbledegook.

Fortunately I had a computer history background and realized I was getting a perfectly sensible response...in EBCDIC.

The endpoint accepted incoming ASCII but responded in EBCDIC? Or was this a binary packet with some EBCDIC-coded strings?

I was getting an error message back, apparently. So I needed to send EBCDIC too, but apparently nobody thought to document this anywhere.

It wasn't binary, but it was fixed length fields, which were surprising common in those days.

and hollywood tries to make us believe that we can easily talk to alien systems

Avoid the issue: assign UUIDs to everybody.

I worked with a registration system that assigned every attendee a UUID, the issue with that is, most conventions have a badge number, as badge names are generally non-unique.

The developer saw no issue with making people enter UUID's to search for badges.

Never had to actually build it, but I've had to explain to multiple people over the years why a dropdown select element for ZIP CODE is a bad idea.

Free text fields still tell me mine doesn't exist (in their years out of date database) so I wouldn't be worse off with a drop-down.

I had a customer who refused to go to a second screen to add or edit customer transactions. They wanted one screen, dammit. So they got one screen. When a customer renewed their membership the user retyped the data on row two in row three, then row two in row one, and then added the new transaction to row one because that was "easier.". Mmmkay.

Why was this easier than just swapping the IDs between Manufacturer #1 and the problem client?

Likely this would have led to every other sync partner conflating the two records. I doubt they built support for "changing primary key" into their system, and even if they tried, once ID 1 meant two things depending on the time of the change, a 2-way sync can't be relied upon (since the timestamps might conflict).

Because every used had the list of numbers, the number was already in use, and changing the actual numbers would require interaction with every user of the inventory system.

Then once word got out that you were willing to modify this system to suit one customer’s ego, it would be open season for everyone to make ridiculous requests (“we really like 69. Can we be 69?”)

this is when uuid would be nice, or at least 6+ digit non-sequential ids...

Reply on news.ycombinator.com