5 ms·

As a general rule, the earlier an industry automated their systems, the worse the implementation. In the earlier decades of computing, the software industry re

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.

ozim 7y ago
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.
- mattmanser 7y ago
  No, as others have mentioned the reason for this was to save bytes or bandwidth when bytes and bandwidth were really expensive.
  - rdiddly 7y ago
    That's what others here have conjectured. Suddenly it's authoritative?
    - dredmorbius 7y ago
      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) 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/IBM_7090 https://en.wikipedia.org/wiki/FLOPS https://en.wikipedia.org/wiki/FLOPS
      - rdiddly 7y ago
        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.
        dredmorbius 7y ago
        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 http://www.amadeus.com/bg/documents/aco/bg/basic-qrg.pdf
        deleted 7y ago
        [deleted]
        rdiddly 7y ago
        Well I'm convinced then. That's nuts. Not so much that something so crappy can exist, but that it can persist!
    - coldtea 7y ago
      Yes, because some of the "others" were actually there, then...
- FpUser 7y ago
  "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.
  - chris_wot 7y ago
    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.
    - FpUser 7y ago
      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.
- jschwartzi 7y ago
  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.
wayoutthere 7y ago
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.
- deleted 7y ago
  [deleted]
- kingbirdy 7y ago
  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.
  - naniwaduni 7y ago
    This interpretation imputes a principled separation of the "CLI" from the "data storage side". Not a winning bet.
  - solstice 7y ago
    Would be interesting to know whether other people whose names end in mr also have this problem
- adrianmonk 7y ago
  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.
- vmurthy 7y ago
  > 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.

ozim 7y ago

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.

mattmanser 7y ago
No, as others have mentioned the reason for this was to save bytes or bandwidth when bytes and bandwidth were really expensive.
- rdiddly 7y ago
  That's what others here have conjectured. Suddenly it's authoritative?
  - dredmorbius 7y ago
    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) 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/IBM_7090 https://en.wikipedia.org/wiki/FLOPS https://en.wikipedia.org/wiki/FLOPS
    - rdiddly 7y ago
      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.
      - dredmorbius 7y ago
        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 http://www.amadeus.com/bg/documents/aco/bg/basic-qrg.pdf
        deleted 7y ago
        [deleted]
        rdiddly 7y ago
        Well I'm convinced then. That's nuts. Not so much that something so crappy can exist, but that it can persist!
  - coldtea 7y ago
    Yes, because some of the "others" were actually there, then...
FpUser 7y ago
"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.
- chris_wot 7y ago
  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.
  - FpUser 7y ago
    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.
jschwartzi 7y ago
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.

wayoutthere 7y ago

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.

deleted 7y ago
[deleted]
kingbirdy 7y ago
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.
- naniwaduni 7y ago
  This interpretation imputes a principled separation of the "CLI" from the "data storage side". Not a winning bet.
- solstice 7y ago
  Would be interesting to know whether other people whose names end in mr also have this problem
adrianmonk 7y ago
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.
vmurthy 7y ago
> 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.