But can somebody help me understand? Flexport seems to be a 3PL (third party logistics) company marketing itself as a software company. There are literally thousands of 3PL companies though. What's the difference between Flexport and say DHL/DSV/UPS/Geodis Wilson/Toll/Yusen/<insert your local 3PL provider>, other than snappy marketing and a position in YCombinator?
For comparison. There are software companies that provide software to many 3PL companies, and don't do any actual 3PL themselves.
He's claiming they enable clients to navigate the many 3PLs. He claims to offer you the client company, the software, that will let you ship your stuff through any 3PL. He's a broker.
Flexport is a freight forwarder. You tell them where you want your international shipment to go and they make all the arrangements with the various intermediaries to get it from origin to destination and through customs. I’ve worked with a bunch of freight forwarders and Flexport’s software is far and away the best that I’ve encountered. Most freight forwarders operate on email and Google Sheets. You constantly have to call and prod them to get updates on your shipment. With Flexport everything is in their app and they have good behind the scenes systems for keeping shipment info up to date. It’s kinda hard to explain how much better of an experience they provide to someone who’s never had to deal with freight forwarders.
Flexport started to "disrupt global trade" (in a positive sense) and ended as a global freight forwarder. The latter is impressive enough, just a tad short of the initial goal.
One software house that I like a lot in the logistics space is WiseTech, a lot of the big shots, e.g. DHL are using it.
Yeah, for sure, a lot of traditional freight forwarders and 3PL providers don't have fancy API's and tracking. But there are certainly a lot that do. And some of those have vertical integration (and therefore potential for massive internal cost savings). I'm not seeing the potential for market disruption in comparison to these players, other than perhaps the massive cash injection Flexport has that these companies don't.
To me, the story of Flexport is, "We spent 1 billion dollars, and now we have a profitable Freight Forwarder", which for sure is an amazing success story because that is not easy, but also all their competitors are in their own way pretty amazing.
Ya, if you can optimize this quaters earnings by 6% at the expense of your business literally potentially collapsing in 3-5 years, that is considered optimal under our present system of shareholder ownership. Shareholders by their very nature don't need to care about stewardship or longevity of a business because they own a small portion of a company for a short time.
Outside of critical supplies (food, energy, medicine), I suspect the answer is the ROI of robustness is negative. People can wait an extra year for their Xbox and stretch a few more years out of their car if it's once a generation.
During the first weeks of covid, the shortage of simple things such as face masks and disinfectants (even when the authorities were still saying such masks were useless), made me anticipate the following:
- Countries will start to move away from a JIT supply chain over country borders, and move towards a setup where they can ensure their more important goods/components can be produced either domestically or with their most trusted allies.
- As the pandemic was not likely to end until good vaccines were available, and flock immunity reached, the economic direct effects would be likely to last for 1-3 years.
- During this time period, global lockdowns and limitations in transportation would lead to devestated supply chains, globally.
- During that period, governments would be likely to start WW2-level public spending to ensure the basic needs of the population were met, and not worry so much about what comes after.
- For the US, I expected this to be true, even if Trump would win the election, but if he didn't, I predicted that Democrats would be obligated to spend even more than Trump would have.
- Eventually, these factors would all contribute to severly constrain the supply side of the economy, while government spending/money printing would ensure the demand side remained strong
- This imbalance would trigger a massive increase to inflation, and most probably stagflation.
- These changes would in turn lead to increased conflict levels both within nations and between them. Basically, increased frequencies of wars, strikes, mercantilism, tarrifs and trade wars/sanctions.
- These actions would in turn ensure that the economic crisis would drag out for years after the economy could otherwise be returned to something close to normal.
According to this timeline, what remains is primarily more conflict, and perhaps in particular massive strikes in many countries that will weaken the supply side further, and prolong the ongoing stagflation, perhaps 10 years or more, before we come to our senses. (Especially if China invades Taiwan).
The correct question to ask about technology is "... For who?"
For who within the supply chain will software make things simpler? Who benefits?
Rarely, technology makes things simpler for all parties. It might make the customer's life simpler, or the maintainers, etc. But a lot of technology exists to make some folks wealthier at the expense of others.
So in this case, who benefits? It seems like the consumer and the entity shipping goods as part of a global supply chain.
That's a good point. Software will add rigidity when applied to automated processes. I'm not sure the supply chain world needs more rigidity right now.
I'd say, yes, to a point. Maybe it depends on the definition of supply chain. Transportation is, in my opinion, a very small part of the chain.
Moving atoms is very different from moving bits and bytes with software. For example, we buy custom aluminum extrusions and other custom-manufactured metal components. The design, validation, sourcing, manufacturing and inspection process is months long.
Transportation is that little --important, of course-- sliver of time that happens at the very end of all of that. There's a lot more complexity in an end-to-end supply chain than most people realize. Even buying a screw isn't simple. Software can only touch some of these parts. I'd say very few of them, actually.
A recent case. Custom aluminum extrusions. Flexport air-freighted the shipment for us because ocean freight would have taken a million years. The shipment was --we are told by those we contracted to do it-- inspected per our specifications. Well, the shipment was crap. We probably had to throw out half of it. It didn't matter how efficiently it got from point A to point B. The failure happened way before that.
This is why very large companies have their employees on site to manage quality. If you don't operate at those scales you can be victimized in ways I cannot even begin to describe.
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)
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.
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.
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.
> 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.
> 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.
Just because it's been in use for a long time doesn't mean it's any good. It only means it's good enough that they can keep enough clients to stay in business. And when it comes to logistics, a lot of times the quality of the tech integration is way down the list in terms of decision factors, like price or the ability to handle some special needs you might have.
We have plenty of problems with this system, some of which require our ops people to get on the phone and for instance find out why the number of orders they see in weekly reports don't perfectly match the reporting we have through the EDI.
> 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.
It's fine as a data transfer protocol, but it's terrible as a real-time communication interface. Yes you can use sftp to exchange messages, but if we want to send an order out and give the customer confirmation as soon as possible that it's been confirmed, REST is the right tool for that job and sftp is a square peg that's been trimmed down to fit inside a round hole.
Using REST to solve a problem like this is not about being "fashionable", it's simply about using the right tool for the job. We're not talking about GraphQL and protocol buffers, REST is an old and extremely well-tested approach to web services, and has won because it's so well fit to the problem it solves.
And there's a huge benefit to standardizing web service interfaces. It means that any 3rd party you work with already knows how to talk to your system, and can just focus on which data has to be passed back and fourth. You don't have to teach your clients how to communicate with you via some arcane in-house protocol which has weird corners you only find out about once you start to work with it, like the system breaks if the documents come in the wrong order or something.
By not offering the modern standard, these kinds of businesses make it slower and more expensive for clients to work with them. If I am trying to get a product to market, give me a REST API and I can have warehouse integrated in a week or two. With some proprietary protocol who knows how long it is going to take.
This system is also solvable without a rewrite. If your system is so complicated and arcane that it's impossible to re-write it, just wrap it in a REST service. Your REST service can talk to sftp or whatever crazy system you want to come up with. But there is zero benefit to deviating from the standard from the client's perspective.
> Just because it's been in use for a long time doesn't mean it's any good.
Not conclusively, but I would argue that on average, code that is still in production after 28 years is going to provide a higher ROI over its lifetime than code written yesterday.
In other words, the age of the code doesn't prove conclusively that it is either good or bad, but higher age is an INDICATION (as in correlation) of higher quality (at least for the time it was written).
> We have plenty of problems with this system,
Had you argued based on this, instead of the age, I would not have objected.
> It's fine as a data transfer protocol, but it's terrible as a real-time communication interface.
Again, had you specified that ftp/sftp was used for real time communication, I would not have objected. (It would have been fine for the 90's though, and might still be in use if it was completely stable.)
> Again, had you specified that ftp/sftp was used for real time communication, I would not have objected. (It would have been fine for the 90's though, and might still be in use if it was completely stable.)
Hahaha, I've seen enough of that sort of stuff that I immediately assumed the reason they objected wasn't the tech but because it was being grossly misused, kind of like trying to build a distributed lock-like-thing on top of S3 or any of a number of other sorts of atrocities you might see with more modern tech.
As a buyer in much smaller part of the supply chain, my experience is that no-one who uses the supply chain wants a simpler supply chain, they want to meet their business goals. If you use software to simplify your supply chain, you'll use that to do more complex things with the supply chain until the gains are erased.
39 comments
[ 3.4 ms ] story [ 99.5 ms ] threadMade easier or faster? Sure. Made a profitable wedge into some existing business (a.k.a. disrupted)? Absolutely!
But adding layers of complicated stuff only experts understand rarely makes anything simpler.
Not to knock Ryan Petersen. He never made that claim once in the entire interview.
But can somebody help me understand? Flexport seems to be a 3PL (third party logistics) company marketing itself as a software company. There are literally thousands of 3PL companies though. What's the difference between Flexport and say DHL/DSV/UPS/Geodis Wilson/Toll/Yusen/<insert your local 3PL provider>, other than snappy marketing and a position in YCombinator?
For comparison. There are software companies that provide software to many 3PL companies, and don't do any actual 3PL themselves.
One software house that I like a lot in the logistics space is WiseTech, a lot of the big shots, e.g. DHL are using it.
To me, the story of Flexport is, "We spent 1 billion dollars, and now we have a profitable Freight Forwarder", which for sure is an amazing success story because that is not easy, but also all their competitors are in their own way pretty amazing.
3-5 is pessimistic. This was a p99 event. You can count on some level of government bailout for those.
For example, nearly the entire car industry is impacted by supply chain problems. The result has been fewer cars sold for higher prices.
- Countries will start to move away from a JIT supply chain over country borders, and move towards a setup where they can ensure their more important goods/components can be produced either domestically or with their most trusted allies.
- As the pandemic was not likely to end until good vaccines were available, and flock immunity reached, the economic direct effects would be likely to last for 1-3 years.
- During this time period, global lockdowns and limitations in transportation would lead to devestated supply chains, globally.
- During that period, governments would be likely to start WW2-level public spending to ensure the basic needs of the population were met, and not worry so much about what comes after.
- For the US, I expected this to be true, even if Trump would win the election, but if he didn't, I predicted that Democrats would be obligated to spend even more than Trump would have.
- Eventually, these factors would all contribute to severly constrain the supply side of the economy, while government spending/money printing would ensure the demand side remained strong
- This imbalance would trigger a massive increase to inflation, and most probably stagflation.
- These changes would in turn lead to increased conflict levels both within nations and between them. Basically, increased frequencies of wars, strikes, mercantilism, tarrifs and trade wars/sanctions.
- These actions would in turn ensure that the economic crisis would drag out for years after the economy could otherwise be returned to something close to normal.
According to this timeline, what remains is primarily more conflict, and perhaps in particular massive strikes in many countries that will weaken the supply side further, and prolong the ongoing stagflation, perhaps 10 years or more, before we come to our senses. (Especially if China invades Taiwan).
For who within the supply chain will software make things simpler? Who benefits?
Rarely, technology makes things simpler for all parties. It might make the customer's life simpler, or the maintainers, etc. But a lot of technology exists to make some folks wealthier at the expense of others.
So in this case, who benefits? It seems like the consumer and the entity shipping goods as part of a global supply chain.
1. What is the problem that this new technology solves?
2. Whose problem is it?
3. What new problems do we create by solving this problem?
4. Which people and institutions will be most impacted by a technological solution?
5. What changes in language occur as the result of technological change?
6. Which shifts in economic and political power might result when this technology is adopted?
7. What alternative (and unintended) uses might be made of this technology?
<https://scottberkun.com/2016/the-7-questions-for-any-technol...>
<https://yewtu.be/watch?v=dBlfPhsrvtw>
<https://yewtu.be/hlrv7DIHllE?t=50m34s>
From Technopoly: <https://www.worldcat.org/title/30337681>
Related: Postman's Five Laws of Technology:
1. “All technological change is a trade-off.”
2. “The advantages and disadvantages of new technologies are never distributed evenly among the population.”
3. “Embedded in every technology there is a powerful idea.”
4. “Technological change is not additive; it is ecological.”
5. “Technology tends to become mythic.”
<https://pggalalis.com/postmans-five-laws-of-technology/>
(More detail at the link.)
I'd say, yes, to a point. Maybe it depends on the definition of supply chain. Transportation is, in my opinion, a very small part of the chain.
Moving atoms is very different from moving bits and bytes with software. For example, we buy custom aluminum extrusions and other custom-manufactured metal components. The design, validation, sourcing, manufacturing and inspection process is months long.
Transportation is that little --important, of course-- sliver of time that happens at the very end of all of that. There's a lot more complexity in an end-to-end supply chain than most people realize. Even buying a screw isn't simple. Software can only touch some of these parts. I'd say very few of them, actually.
A recent case. Custom aluminum extrusions. Flexport air-freighted the shipment for us because ocean freight would have taken a million years. The shipment was --we are told by those we contracted to do it-- inspected per our specifications. Well, the shipment was crap. We probably had to throw out half of it. It didn't matter how efficiently it got from point A to point B. The failure happened way before that.
This is why very large companies have their employees on site to manage quality. If you don't operate at those scales you can be victimized in ways I cannot even begin to describe.
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)
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.
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.
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.
Just because it's been in use for a long time doesn't mean it's any good. It only means it's good enough that they can keep enough clients to stay in business. And when it comes to logistics, a lot of times the quality of the tech integration is way down the list in terms of decision factors, like price or the ability to handle some special needs you might have.
We have plenty of problems with this system, some of which require our ops people to get on the phone and for instance find out why the number of orders they see in weekly reports don't perfectly match the reporting we have through the EDI.
> 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.
It's fine as a data transfer protocol, but it's terrible as a real-time communication interface. Yes you can use sftp to exchange messages, but if we want to send an order out and give the customer confirmation as soon as possible that it's been confirmed, REST is the right tool for that job and sftp is a square peg that's been trimmed down to fit inside a round hole.
Using REST to solve a problem like this is not about being "fashionable", it's simply about using the right tool for the job. We're not talking about GraphQL and protocol buffers, REST is an old and extremely well-tested approach to web services, and has won because it's so well fit to the problem it solves.
And there's a huge benefit to standardizing web service interfaces. It means that any 3rd party you work with already knows how to talk to your system, and can just focus on which data has to be passed back and fourth. You don't have to teach your clients how to communicate with you via some arcane in-house protocol which has weird corners you only find out about once you start to work with it, like the system breaks if the documents come in the wrong order or something.
By not offering the modern standard, these kinds of businesses make it slower and more expensive for clients to work with them. If I am trying to get a product to market, give me a REST API and I can have warehouse integrated in a week or two. With some proprietary protocol who knows how long it is going to take.
This system is also solvable without a rewrite. If your system is so complicated and arcane that it's impossible to re-write it, just wrap it in a REST service. Your REST service can talk to sftp or whatever crazy system you want to come up with. But there is zero benefit to deviating from the standard from the client's perspective.
Not conclusively, but I would argue that on average, code that is still in production after 28 years is going to provide a higher ROI over its lifetime than code written yesterday.
In other words, the age of the code doesn't prove conclusively that it is either good or bad, but higher age is an INDICATION (as in correlation) of higher quality (at least for the time it was written).
> We have plenty of problems with this system,
Had you argued based on this, instead of the age, I would not have objected.
> It's fine as a data transfer protocol, but it's terrible as a real-time communication interface.
Again, had you specified that ftp/sftp was used for real time communication, I would not have objected. (It would have been fine for the 90's though, and might still be in use if it was completely stable.)
Hahaha, I've seen enough of that sort of stuff that I immediately assumed the reason they objected wasn't the tech but because it was being grossly misused, kind of like trying to build a distributed lock-like-thing on top of S3 or any of a number of other sorts of atrocities you might see with more modern tech.