Hacker News Reader

Comment by adrianmonk | Hacker News Reader

As a general rule, the earlier an industry automated their systems, the worse the implementation.

In the earlier decades of computing, the software industry really just didn't know what it was doing too much. (Not that we're perfect now, but we were even worse back then.)

And replacing an implementation is a huge undertaking, and a lot of industries just don't bother.

This leads to a paradoxical situation where industries that most obviously need automation are the ones that have the worst automation. Before others, they pushed to get it done, and they got locked in to something primitive and/or outmoded.

View on HN

I mean, it doesn't hurt that hardware now is so fast and scalable that performance and efficiency can take a back seat to usability and clarity. Guarantee this was done because storing the title as part of the first name field saved a few bytes over having a separate field, and that really mattered in the 70s when these systems were designed.

Based on the top answer, this appears to be an error in the CLI "helpfully" re-interpreting Amr as { First name: A, Title: Mr }, not an issue on the data storage side.

This interpretation imputes a principled separation of the "CLI" from the "data storage side". Not a winning bet.

Would be interesting to know whether other people whose names end in mr also have this problem

Yeah, it is a mixture of causes. Sometimes hardware constraints really did force software into tough choices.

The C programming language might be a good example. From a modern perspective, requiring forward declarations seems like pointless busywork. At the time it was written, decisions like that made it possible to have a one-pass compiler, which was an important efficiency gain. You could reduce I/O and maybe save RAM.

> it doesn't hurt that hardware now is so fast and scalable that performance and efficiency can take a back seat to usability and clarity.

Agree. Unfortunately , the users of even the new usable systems may be loath to take up these changes. Why? I guess inertia and priorities. My mind goes back to QWERTY v/s Dvorak and how it panned out.

The top answer on StackExchange alludes to this, too.

My mind goes back to QWERTY v/s Dvorak and how it panned out.

Sometimes the new system isn't better so there's no reason to switch... AFAIK, Dvorak is not better than QWERTY (despite claims to the contrary).

I worked in IT at a hotel company when they made the cutover from a 3270 based text system to an early 90's modern Windows GUI -- agents hated it, even with command shortcuts it was slower than the old interface. Training new agents was faster, but experienced agents were much slower.

It is nice to see it when we get first implementation where "business" invents some rules, like only 2 items for this list or something like that.

Next month when feedback from user comes, we are removing loads of rules that were supposed to be helping.

So with agile we are better now because we can remove stupid rules in next iteration and not leave it hanging there for decades.

No, as others have mentioned the reason for this was to save bytes or bandwidth when bytes and bandwidth were really expensive.

That's what others here have conjectured. Suddenly it's authoritative?

Look up two-digit date fields, packed-decimal, zoned-decimal, bitfields, and other encoded-field datatypes. All were explicitly created to save on data storage, when the main transmission medium was punch cards.

The rationalisation is not conjecture. It's fact. Bits and baud were expensive.

And that's before getting to bitshifted storage of software and similar tricks.

SABRE dates from the 1950s. Which was a long time ago in Internet Years.

https://en.wikipedia.org/wiki/Sabre_(computer_system)

The computer it was based, the IBM 7090, on had memory storage of 32,768 words of 36 bits, about 64 KB using today's 16-bit byte. It operated at 100 kflops/s. A modern AMD-64 CPU tends around 4-64 flops per cycle, or in the neighbourhood of 4-250 gigaflops/s, up to about 2 billion times faster.

https://en.wikipedia.org/wiki/IBM_7090

https://en.wikipedia.org/wiki/FLOPS

I've programmed on punched cards. System/360, FORTRAN77. Carter administration.

Whether history exists or not, is not the question. Whether byte misers from long ago caused this name-mangling issue, that's the conjecture part. At least one aspect of the guy's complaint was of recent origin, and ironically that was from arbitrarily insisting the name be longer than it is.

The SE answer links to the relevant documentation. Spaces are indeed optional. It's not explicitly documented that a non-whitespaced 'MR' is read as a title, but it seems likely.

http://www.amadeus.com/bg/documents/aco/bg/basic-qrg.pdf

Well I'm convinced then. That's nuts. Not so much that something so crappy can exist, but that it can persist!

Yes, because some of the "others" were actually there, then...

"So with agile we are better now because we can remove stupid rules in next iteration and not leave it hanging there for decades."

Nice try. Fixing bugs and changing bad logic in timely manner were done ages ago when nobody knew that Agile term.

Yes, but in many cases the rules were not fixed also. Agile is a mindset and philosophy. Whilst not a panacea, i feel it does help reduce inertia in organisations that adopt it.

Yes, but in many cases the rules were not fixed also

What does this have to do with Agile? You either have adequate resources (human and money) and desire to fix problems or not. Absent that issues and bugs are lingering for years in organizations that employ agile. I saw it with my own eyes.

Agile doesn't help you here. It might only take a day to fix this issue in your code base. But then it will take months to get it tested and approved. And then it has to be rolled out into the organization and periodically analyzed during the rollout until it's done. Given how large airlines are and how many people interface with an airline booking system Agile's "contribution" to development timing is meaningless here. You could spend a day making a fix and a couple years watching that fix slowly percolate into the organization, followed by another couple of years waiting for all the travel agents to stop calling and complaining about how this impacts the workflow they've had for the last 20 years.

Reply on news.ycombinator.com