Amount of driven kilometers are also up massively compared to 1985, meaning that per kilometer we did fine on the safety record.
Stop trying to make cars safer, and reduce the amount of driving you need to do. There is a way to have more liberties and have it improve safety instead of fewer. The liberty to commute, do groceries, and go to the gym by bike is huge life improvement, whilst taking nothing away in terms of car liberties.
I get it, you like stories of individuals. We should figure out a way you can listen to more stories, so you can form an even better opinion! Perhaps we write them out, shorten them a bit. Or perhaps group them by similarity. And then if we count the types of story per category… and boom, we’ve invented statistics!
And ...boom! we lost the nuance, and shoehorned together disparate elements into a bunch of measurements, as if those explain everything (as opposed to needing explanations and a working theory themselves, and often fitting multiple theories about how they came about).
Not to mention the cases where the numbers are collected or analyzed in bogus ways (from wrong methodologies and false reporting, to p-hacking), and people are asked to cargo cult respect them anyway...
And I know how to tell any story, it's called lying. Whether you are lying with statistics or lying in a story does not matter. In the end it all comes down to whether you can validate what you've been told. Most people however will skip validation in favor of 'this sounds reasonable' and most people have a worse intuition for statistics than for stories. That's on them though, let's not blame statistics for that shortcoming.
The point is that if you have over 100 correlates to assess a situation, any particular story you try to tell is probably a lie even with the best intentions.
That depends. I'm perfectly happy as a European business owner that it is made very clear that accessible software is not optional, and even if you think it is expensive, that you can't just sit around and wait for the fine to hit.
The reality is that if you're ignoring this stuff, you are effectively eliminating a significant chunk of the population from participating in public life. It's about as bad as not having wheelchair ramps in public places, except the same software runs everywhere, so it's not the one virtual 'building' missing it, but all buildings made by the same architect.
So let me get this straight: because the US wont let you get the sales tax you paid back like you would with a VAT, you blame the "sane" system for effectively imposing an import tax, even though there is no way for the that receiving system to know how much sales tax was paid already and deduct it properly?
I'll gladly flip that argument on its head: the US is imposing an export tariff, since everything sold from the US to Europe includes US sales tax in the process, while in the inverse, any EU company charges 0% VAT to the US.
Open source means being able to verify how the sausage is made. Getting a premade sausage and saying “oh you can still eat it and spice it up however you like” isn’t that.
I’m happy open weights exist, but it is not truly open source.
You should look into Secure Container Release, Certified PickUp, Secure Chain, and a whole bunch of other initiatives doing this. Here is the Dutch one: https://www.portbase.com/en/programs/secure-chain/
So about truck appointment systems, you should probably be thankful those are NOT the norm. Generally speaking container terminal operators and transport companies are antagonistic to eachother, since they are NOT in a direct business relationship. The truck transporter (or rail/barge transport companies) are hired either by the shipper directly, or by the shipping company, depending on whether you book a door-to-door or a port-to-port transport. This is also known as carrier haulage and merchant haulage. The container terminal generally works for the shipping line.
Long story short: the container terminal will always opt to please their customer (shipping line) over their non-customer (trucking companies). Truck appointment systems are usually used to force transporters to smooth out peak times not in the name of efficiency, but rather to lower the amount of dock workers the container terminal needs to hire. The truck companies generally end up footing the bill for this, both in increased workload and in detention/demurrage costs because they can't get their containers out and back in time. This money goes directly into the pocket of both the shipping line and container terminals as this is typically something they make heavy profits on.
Be very wary when container terminals and shipping lines start to push for centrally mandated appointment systems. They are much more consolidated than hinterland transport operators. I'm all for increasing efficiency but let's not even further increase market power for shipping lines and container terminals please.
> smooth out peak times not in the name of efficiency, but rather to lower the amount of dock workers the container terminal needs to hire.
I’m confused. Efficiency means you don’t need to hire as much, since your peak-to-trough ratio is lower. Or you can handle more load, if you were capacity-constrained.
I don’t get why this is framed as a secret “other reason”.
My understanding is that shipping is a competitive market, is this not the case? If it is you expect price decreases to be passed on to customers.
Container terminals will take any minor efficiency win on their side, even if it comes at the cost of massive efficiency loss for truck transporters. It's optimizing for a local maximum. The market is structured in such a way that it is hard to correct for that, since the relation between trucking companies and container terminals is very indirect, and customers can't directly compare.
Also while shipping is a competitive market, the market for ports is not. You're either in a location or not. There are not hundreds of container terminals in a single port in competition because of economies of scale.
(The market for trucking companies IS competitive however, meaning that if you have to err on 'protecting' either party, you should probably pick that one)
> about truck appointment systems, you should probably be thankful those are NOT the norm
Sounds like you’re arguing against a port-run appointment system versus a system per se. When I said centrally-managed I should have said federal. It strikes me as analogous to ATC.
ATC does not take appointments. Planes arrive early and late all the time. All ATC offers is _sequencing_ through protected airspaces. Your pilot is literally picking up their actual clearance on the ground right before engine start.
Planes can declare emergencies, they can divert to alternative locations, turn around for maintenance issues. And this is just IFR flights. VFR flights can take off, and once outside of controlled airspace, can just fly mostly however they want.
Your doctor takes appointments. That's a more apt analogy for what port appointments will create.
That’s actually not true for airlines, which are the better analogy here. For airline traffic airports have slots, which are basically appointments, attached to fixed flight schedules.
At the most congested airports slots are highly valuable, to the point where they’re often listed separately as part of an airline’s assets, and airlines will sometimes trade slots.
Many countries will fine airlines if they miss their slot time for reasons that aren’t related to emergencies or bad weather, as well as fine them for any other slot misuse such as hoarding, strategic cancellation, etc.
Now, sure, it’s not a case where if you miss the slot you can’t land or take off. The airport and ATC will always try to accommodate flights no matter what. But it usually means fairly substantial delays to avoid impacting on other take off, landing, and gate slots.
Slots have a very wide time range so thinking of them as "appointments" is entirely misleading.
Also airlines have been given waivers since the early 2000s because the FAA realized that they were simply operating empty "ghost flights" merely to keep their slots allocated to them. So we just give them waivers every year so they don't waste fuel on this stupidity.
The ATC/FAA model is entirely inappropriate for ports.
That’s not the case globally. Heathrow for instance has strict slot time ranges. As does Schiphol.
Neither the UK nor the Netherlands choose to not enforce slot misuse. We’re not talking only about the US and the FAA as examples here.
Whether it’s an appropriate model for ports and especially truck traffic at ports is a different topic, one I’m not qualified to speak on. I was just pointing out the misconception on how airline traffic at airports works and how it’s certainly not just a first-come, first-served ad hoc model.
Slots aren’t managed by ATC. They’re typically managed by the airport as there’s a whole host of facilities impacts to a slot, not just the airspace aspect.
If ATC does not take appointments, they do give appointments. Useful search term is “expect further clearance.” If all else (e.g. your radio) fails, you can plan to have that space reserved at the time indicated.
I’d argue, of course, that when you file a plan, you’re requesting an appointment.
Agreed, with the asterisk that shipping companies and terminals will try to be the ones driving the government agendas on this. Government run does not necessarily equal neutral. But a neutral system I am generally in favor of.
"Long story short: the container terminal will always opt to please their customer (shipping line) over their non-customer (trucking companies)." Right.
Here's a video from the trucker's viewpoint.[1]
If the container terminal had to pay for the trucker's time from the moment they entered the queue to enter the port until they left the exit gate, there would be more active loading stations.
That's not true in my experience. Loading outbound cargo is way more complex, since the stowage plan of the ship dictates where each container goes. Theoretically a lot of containers can be swapped as long as weight is similar, the container type is identical, and the port of discharge is the same. In practice it's still incredibly complex compared to just unloading stuff. While you may need to do less 'digging' on shore, the nitty gritty of the actual operations are way more complex than throwing some boxes ashore.
Import cargo is annoying in that it is mostly random access on pickup. For pickup by train, barge, or feeder ship, a vast minority, you typically don't have cargo manifests until a day or two before pickup at best, so in practice this is also random access-ish. The customs processes are also trickier.
My experience is mostly in Rotterdam and Antwerp, and I'd say the problems in the US probably don't have to do much with automation. Rotterdam and Antwerp have very different automation levels at the biggest container terminals, yet productivity is quite similar.
There is lots of low hanging fruit in optimizing operations, like more collaborative stowage planning, simultaneous unloading and loading operations, and 'modal shifting' from road to rail and water combined with early preannouncement of manifests for trains and barges.
Disclaimer: I'm in the business of consulting and building software for container terminals, so I'll generally be biased towards those solutions.
Unloading can be complex also I would think, in that you have to maintain balance on the ship so it doesn't list or even roll over. You can't just grab the nearest container with your crane.
As a general rule, container ships are unloaded tier-by-tier, breadth-first if you will, not shaft-by-shift (depth-first), so this is not much of a problem in practice.
That does start to change if you want to do simultaneous loading and unloading operations, then you'd want to clear out a vertical shafts first so you can start loading operations as quickly as possible. Which is one of the many reasons dock workers hate that style of operations.
That's a pretty reasonable mental model. The only real requirement during unloading is ship stability, other than that just use max concurrency with all the cranes and equipment to max throughput. Even just on the crane level, you can just keep unloading stuff to shore, and wait until vehicles pick them up. If they are slow, just keep on unloading until they catch up. Chance of stalling ops is close to zero.
Loading operations are much more variable, especially if your yard is not stacked well and you need to 'dig out' specific containers. If you run out of containers underneath your crane, your operations are stalled until the terminal vehicles catch up and bring you new boxes to load.
> Even just on the crane level, you can just keep unloading stuff to shore, and wait until vehicles pick them up. If they are slow, just keep on unloading until they catch up. Chance of stalling ops is close to zero.
It's not done that way, much. When a container is taken off a ship, it's usually placed on something that moves - a truck chassis, a railroad car, or an AGV. If you clutter up the dock with containers, unloading will stall.
Fair enough, I was thinking of terminals one step smaller where reachstackers or straddle carriers directly drive to and from the quay. On bigger terminals it’s a much more interlinked process indeed.
This is a small container port with a two lane access road. Not much traffic. No automation.
Container stacks are only two high, three high at most.
Driver is led through stacks of containers until they find the one they want to pick up. After some yelling, someone driving a stacker removes the container from the top of the one they want, then loads
the desired container onto the truck chassis.
Although there's one container ship at quayside, no loading or unloading seems to be happening.
Yep, that's more my class of customers. The height limitation is probably because of the gantry crane. In my experience having the truck driver follow the reachstacker is kind of uncommon, you'd ideally either tell the truck driver where to go from the gate, or just have the stacker drive across the terminal. This seems like the worst of both worlds. Perhaps a union or regulation thing about minimizing driving around with a reachstacker holding a box?
Fascinating business nonetheless, this is definitely something different than I'm used to over in NL/BE. Thanks for sharing!
We’ve done this for an SME customer of ours. We were essentially building a new module on top of their existing in-house systems. We laid out our query patterns in advance so they could index properly, and only query specific views. Write-out is only in tables dedicated for our product.
It works surprisingly well, and is pretty resilient since it essentially acts as a message queue too. Then again, this is all low traffic stuff in a SME / B2B setting, with zero multitenancy involved.
I’ll still take a proper API or message queue any day though.
Edit: I suppose our biggest benefit is that our customer can actually change the interface with us fairly quickly. Then have database experts in-house, but devs who could do APIs. So the collaboration has been mostly smooth an account of that, and that is a huge advantage compared to them having to outsource any API work. Technically speaking I’m not a fan, but the non-technical results have been useful.
I'd recommend against it, but then again, I'm building software products in this exact space with my launching customer being a 200-300M annual revenue logistics company. I don't think they could do it in-house. You don't give a lot of info on the exact niche you are in, but the username tells me that you're doing containers in European context, most likely shortsea or domestic, not deepsea. Me telling you the ISO6436 type code for your username is either LEG1 or LEGB depending on max stacking height should tell you I know my stuff :)
Your biggest pain point is most likely that you know your business very well, but you probably do not know enough about the business context of your partners. If you are running a small-ish container terminal for example, you really should know how the depot department of the major carriers are managing their empty stock so you can decide your stacking strategies in the yard. You should probably also have an understanding of benefits vs drawbacks of tower cranes vs gantry cranes found at bigger quays. That then influences what your TOS should be capable of. Same thing goes for intermodal transport planning, you really should know not only how detention/demurrage works, but also what tricks you can pull to optimize for it, and how shipping lines monitor this internally. If you are building stuff in-house, you're inevitably going to be limited in your understanding of the wider market. Short term that's a huge improvement (more tailored software, better flexibility), long term that might cause huge issues.
I can certainly understand the frustration with third-party products. Your description of 'they are understaffed and the platform is stagnant' could realistically apply to pretty much any software provider in this space. There is a huge opportunity for somebody to swoop in and build something, the bar for this sector is mostly something that doesn't straight up suck. And I'm going to be honest: we're trying to be that somebody.
If you'd like to talk, my contact details are in my profile. I'm happy to show you what we're building, and tell you what that is like behind the scenes. If you go ahead with your plan to in-house it, let's stay in contact, perhaps we can learn from eachother.
It's also worth mentioning that the economics of software may be very painful. Right now, the cost of building all that software is being shared across all the customers of this company. OP is proposing his/her company bears the entirety of it.
Assume you can hire good sr engineers. This project badly needs some scoping to figure out how much eng time and how much risk it will take to replace what exists.
I've worked on software for small-run scientific instruments: think 200 to 400 sold. The cost of software can be 30% of the total cost of the projects. It may well be that, given what customers are willing to pay, there isn't enough money in this to build good software.
And for OP, for core software, if customers interact with it as well, you likely need follow-the-sun ops too.
> Your biggest pain point is most likely that you know your business very well, but you probably do not know enough about the business context of your partners.
I'm not in the market, but FYI, the tone of your post wouldn't make me want to buy your stuff. You sound too eager to lecture your customers instead of being eager to learn from them.
I didn't get that from the tone. I inferred this person was trying to convey the perceived importance of some critical things and gave good examples with clear knowledge of the problem domain in a limited space. IOW, I thought it was very well articulated and helpful, FWIW.
It's fine to convey the importance of these things. It's another thing to do it with an implied assumption that OP doesn't know better themselves, which context doesn't really give a lot of clues about. Obviously in the end it's a personal thing anyways.
Fair enough. To clarify, my point was not necessarily “I know better”, but that it is incredibly difficult to get a broad view of the market from a single perspective. This market is by definition a chain of steps with parties that may be antagonistic. It is atypical in that way, and writing software in-house may be more difficult in this sector than in others because of it.
While writing software in-house gives you software better tailored to your exact situation it is at the cost of losing the overview of the business and the perspective of the parties you interact with. Whether that trade-off is worth it I’m probably pretty biased on, so take my stance with a grain of salt, but imo the business is intrinsically relatively ill suited for in-house dev considering the high degree of collab with other parties.
Apologies if it came off as arrogance, that was not what I was going for.
> Apologies if it came off as arrogance, that was not what I was going for.
No need to apologize, just wanted to make you aware of how it came off to me.
> my point was not necessarily “I know better”, but that it is incredibly difficult to get a broad view of the market from a single perspective. This market is by definition a chain of steps with parties that may be antagonistic. It is atypical in that way
Maybe? That description sounds like it could probably be applied to any highly fragmented vertical though...
> imo the business is intrinsically relatively ill suited for in-house dev considering the high degree of collab with other parties.
I think this hits a reasonable point — if most of the development is related to internal operations, it could be a different calculus than if it is mostly related to interchange with other parties, which implies knowing enough about their business to make sense to them.
Then again, if all you have to interchange with other parties is a choice of third-rate bottom-of-the-barrel software providers anyways, I think it can still be reasonable to switch to in-house dev.
> You sound too eager to lecture your customers instead of being eager to learn from them.
One does not necessarily exclude the other, in my experience. Personally I love being told when I’m wrong, and I think the OP was actually fishing for this kind of feedback.
My cheesy tagline for this is “The customer is always right about their problems, rarely about the solution to it”. They know their business inside and out, and I’m not about to tell them otherwise. Metaphorically: if they need to cross a river, that doesn’t make them bridge engineers. But boy will they tell me if the bridge is in the wrong place.
Stop trying to make cars safer, and reduce the amount of driving you need to do. There is a way to have more liberties and have it improve safety instead of fewer. The liberty to commute, do groceries, and go to the gym by bike is huge life improvement, whilst taking nothing away in terms of car liberties.