3 ms·

I’ve always felt that the greatest contribution that software development could contribute to supply chain is the UI/UX paradigm. Like so many bureaucratic sys

I’ve always felt that the greatest contribution that software development could contribute to supply chain is the UI/UX paradigm. Like so many bureaucratic systems, it requires expertise to navigate successfully. “No, I didn’t fill out the ID-10-T form, Billy told me to fill out the R3Q-WI.10 and the SF-1053R forms. And, I don’t know what to put in box 1,253-C: what is a “Problem Identification Supervisor Authorization Location NIFPIN”?… I need to go talk to Peggy? Oh, she’s out this week? (Awesome…) What? No, I didn’t… look, no I’m not getting an attitude…” proceeds to be labeled rude and has requisition “slow-walked” Meanwhile, on Amazon, I’ve accidentally bought things because it’s so damned easy to find what I want and spend my money. And, it’s easy and fun. I guess what I’m trying to say is that: computers are incredibly similar to “bureaucratic systems” in that you need to fully understand their inner workings. But, we in the software community take on great efforts to prevent the users from being exposed to all the twine and duct tape that holds the whole thing together. If supply chains were to take UI/UX seriously, businesses would be all the better for it. (Although, saying this suddenly reminds me of all the terrible SAP views and all the gross “internal use” programs we use… sigh)

hef19898 4y ago
What makes you think Amazon is fundamentally different behind what customer see?
- was_a_dev 4y ago
  The complexity of logistics hasn't changed and is no different for Amazon.
  - hef19898 4y ago
    I can confirm that. Amazon is doing it better than most others, for sure, but the effort and complexity is still there. And I'm not sure if looking up tables directly in some database (the Amazon way) and entering data through some cobbled together web interfaces (again, the Amazon way in some cases) is better UI than whatever SAP is providing. I know both, and at least in SAP everything is one place.
  - cupofpython 4y ago
    while true, any big business has a significantly easier time with logistics because they inherently incentivize vendors to conform to their standards. customer service will be the best available from these vendors as well Yes they are ultimately responsible for all the same border crossing paperwork and such, but that is a lot easier when everyone you work with is giving you information in convenient formats and returning your calls quickly. Not to mention the ability to leverage work from past shipments as reference. a small player in this space has a significantly harder time since they have less reference, and vendors are more likely to treat their business as a nice-to-have instead of a want or must-have.
skohan 4y ago
I'm working on a project involving physical manufacturing and fulfillments, and I was honestly shocked how low tech a lot of it is. Like we communicate with one of our warehouses by passing XML documents back and fourth over FTP. It seems like the whole thing was probably set up in 1994 and nobody has touched it since. Working with our own operations people, I have the sense that a lot of it is inertia. People in their field had to figure out how to do all of this before the internet existed for example. And now they busy enough getting their job done through these various arcane systems they're not going to slow down for a few months to learn a new way of doing things. I think as software engineers, we have an intuition about how software could solve a lot of these logistical types of problems efficiently, so we assume it already works that way. Probably we would be shocked how much of the world still runs on handshakes, phone calls, and hand-maintained spreadsheets.
- trashtester 4y ago
  > It seems like the whole thing was probably set up in 1994 and nobody has touched it since. If you write code that doesn't need to be touched over a 28 year period, chances are that code has produced more value (ROI) than 99% of the code that is written every day will ever do. Even 10 years is pretty good. > Like we communicate with one of our warehouses by passing XML documents back and fourth over FTP. Sending XML, CSV or JSON files over sftp is a simple and relatively robust for exchanging data, especially when a latency of minutes to hours is acceptable and the data volumes are non-trivial. > they're not going to slow down for a few months to learn a new way of doing things. New ways of doing things are not always better. Specifically they're not better for all instances. Often, they're radically worse. RESTful API's have many benefits, especially when volumes are low and latency requirements are strict. But if something works perfectly and efficiently, there is often little reason to change it. I've seen a number of cases where some juniorish devs come into a business, identify that some technical system is using an unfashionable stack, started a project to migrate it, and then failed spectacularly. By just focusing on the unfashionable tech involved, many fail to realize all the clever tricks and deep thought that has gone into the original setup, and in many cases they don't even know the old tech well enough to be able to read the original code. Often the orginal setup was the output of a startup full of motivated, clever and sometimes brilliant people who ended up being fairly successful. The team ending up tasked with migrating that system are often overconfident in their skills and superior technical ability compared to the orignal team, but are often staffed by mostly run-of-the-mill developers who are not really of the same callibre as the original startup. Within a few months, they start to realize SOME of the complexity they overlooked the first time, and a couple of years later, most of the new team quit, after realizing they failed. Hopefully after learning a lesson. I've seen instances where MULTIPLE teams have been set up to migrate some legacy platform, each team spending more effort than the original technology cost, and ALL failing.

hef19898 4y ago

What makes you think Amazon is fundamentally different behind what customer see?

was_a_dev 4y ago
The complexity of logistics hasn't changed and is no different for Amazon.
- hef19898 4y ago
  I can confirm that. Amazon is doing it better than most others, for sure, but the effort and complexity is still there. And I'm not sure if looking up tables directly in some database (the Amazon way) and entering data through some cobbled together web interfaces (again, the Amazon way in some cases) is better UI than whatever SAP is providing. I know both, and at least in SAP everything is one place.
- cupofpython 4y ago
  while true, any big business has a significantly easier time with logistics because they inherently incentivize vendors to conform to their standards. customer service will be the best available from these vendors as well Yes they are ultimately responsible for all the same border crossing paperwork and such, but that is a lot easier when everyone you work with is giving you information in convenient formats and returning your calls quickly. Not to mention the ability to leverage work from past shipments as reference. a small player in this space has a significantly harder time since they have less reference, and vendors are more likely to treat their business as a nice-to-have instead of a want or must-have.

skohan 4y ago

I'm working on a project involving physical manufacturing and fulfillments, and I was honestly shocked how low tech a lot of it is. Like we communicate with one of our warehouses by passing XML documents back and fourth over FTP. It seems like the whole thing was probably set up in 1994 and nobody has touched it since. Working with our own operations people, I have the sense that a lot of it is inertia. People in their field had to figure out how to do all of this before the internet existed for example. And now they busy enough getting their job done through these various arcane systems they're not going to slow down for a few months to learn a new way of doing things. I think as software engineers, we have an intuition about how software could solve a lot of these logistical types of problems efficiently, so we assume it already works that way. Probably we would be shocked how much of the world still runs on handshakes, phone calls, and hand-maintained spreadsheets.

trashtester 4y ago
> It seems like the whole thing was probably set up in 1994 and nobody has touched it since. If you write code that doesn't need to be touched over a 28 year period, chances are that code has produced more value (ROI) than 99% of the code that is written every day will ever do. Even 10 years is pretty good. > Like we communicate with one of our warehouses by passing XML documents back and fourth over FTP. Sending XML, CSV or JSON files over sftp is a simple and relatively robust for exchanging data, especially when a latency of minutes to hours is acceptable and the data volumes are non-trivial. > they're not going to slow down for a few months to learn a new way of doing things. New ways of doing things are not always better. Specifically they're not better for all instances. Often, they're radically worse. RESTful API's have many benefits, especially when volumes are low and latency requirements are strict. But if something works perfectly and efficiently, there is often little reason to change it. I've seen a number of cases where some juniorish devs come into a business, identify that some technical system is using an unfashionable stack, started a project to migrate it, and then failed spectacularly. By just focusing on the unfashionable tech involved, many fail to realize all the clever tricks and deep thought that has gone into the original setup, and in many cases they don't even know the old tech well enough to be able to read the original code. Often the orginal setup was the output of a startup full of motivated, clever and sometimes brilliant people who ended up being fairly successful. The team ending up tasked with migrating that system are often overconfident in their skills and superior technical ability compared to the orignal team, but are often staffed by mostly run-of-the-mill developers who are not really of the same callibre as the original startup. Within a few months, they start to realize SOME of the complexity they overlooked the first time, and a couple of years later, most of the new team quit, after realizing they failed. Hopefully after learning a lesson. I've seen instances where MULTIPLE teams have been set up to migrate some legacy platform, each team spending more effort than the original technology cost, and ALL failing.