I understand and I agree with the author points, specially looking to distance yourself from the dependencies these systems are usually entangled with, however:
>But the code examples are in Java and C++ and I do python/JavaScript/ruby/
The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your class", or "think about all the ORM code that you use". None! I use none of that!. And I can't even call any tests because I can't extend a non existant class, there's no objects in here!.
The author also says:
>You need feedback. Automated feedback is the best. Thus, this is the first thing you need to do: write the tests.
I don't need automated feedback. I need to untangle this deep business layer that everything is wrapped around in a 40 years old codebase, with practically no documentation and having to modify one of the core systems of the company. Sometimes I can't even trust the feedback the program outputs. In this kind of scenarios where the code is so messy and limited by technical factors, the best approach I have found is to debug. And that's it. Follow the trail, find the "seam", and then start your kingdom in the little space you can. Because if you tell your boss that you are implementing Unit tests in a 40 years old codebase, the first question he is gonna hit you with is "Why?", and the article doesn't give any compelling argument to answer this.
Yes, the final say is always on the particular custom where the goods will get the clearance, so they will call the shots on the way the procedure should be done.
The IT system in place is just there to accommodate how customs should proceed, so if they have different ways to solve the problem, the customs officer will just find the one he's more used to.
But you're right that if there's a HSCode for something built, furniture vs wood for example, then the more "accurate" should be used, as they will have different tariffs too.
They can, the problem is that if you declare this as different parts then you will have to pay taxes accordingly to the chosen HSCode for each one in the declaration.
If you search for the HSCODE you will find that offshore oil and natural gas drilling and production platforms have their own, 8431434000, which means if you declare only this one you will pay no taxes.
>your grandparents probably read for entertainment instead of tiktok
I strongly disagree. Reading books as activity, maybe. It depends on the person too. But reading itself? In this time and age, we are constantly reading, either in your phone ( even most tiktok videos these days have subs for everything ), browsing the web is a constant reading activity, work/email/essays/whatsapp/telegram, completely outweights the amount of text we read/write now comparing it with our older generation.
I am in a very similar situation, working for a mid-sized logistics (300 employees with small offices around the globe, 400-500M annual revenue), but with a completely different side, we do practically everything in-house with a very old software that does everything, (Multivalue D3).
My experience on your points:
>We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.
We also use low-code applications like Talend and TIBCO, to fill some gaps, the older folks that don't want to deal with our ERP prefer using them this way for example.
We are very slowly migrating our system in different departments to more modern solutions, but always keep in mind that as soon as you start migrating, you will need to keep both systems up for a long period of time while this happens, and that means money and workers.
>On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.
Europe is slowly moving outside of the EDIFACT standard fortunately and slowly implementing SOAP/XML based systems, you will have a problem here in an in-house solution because Europe systems are usually convoluted and hard to implement from different countries, from a business-side pov exclusively. ( I can tell you from first hand experience ), so indeed, a big problem will arise here. If you also do customs clearance, this will get even harder, as laws vary from place to place in small and big details.
>Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning...
Finding them is hard, but keeping them is harder, any other logistics company that sees a trained IT specialist with deep business knowledge will try to poach it with a higher wage inmediatly, I had tons of offers from close companies because of my customs knowledge. Pay them well and keep them happy. There is no strategy here, devs move for money like everywhere else, some end up in banks or insurance after some consultancy job with business experience and stick there, you will have to risk training them in house or poaching them from elsewhere.
For an industry as complex and in my opinion, enterprise customizable company, I highly recommend you to try an in-house solution, users sometimes don't need a lot to do their work and the most important thing in logistics is being able to do it quickly and efficiently.
What I can tell you absolutely that it doesn't work is trying to migrate from a big swoop, I saw companies close to us do it and it just didn't work out, their processes slowed down a lot and clients started fleeing to other forwarders because of the time they took to process any shipment. Move slowly in your smallest department ( reefer, customs, import or export, invocing, anything that in your company isn't as importante) and move efficiently, make their work as fast as possible, then grab that feedback and start moving other departments.
After a couple of years without taking a single one, a couple of months ago I bought a Smint lemon package, I used to love them as a kid so why not taking one for nostalgia's sake.
Since I'm not that used to artificial sweateners ( I dont drink coke or anything related to sugar ), the taste was noticiable inmediatly, it didn't bother me, it was just a curious feeling of being able to detect it so quickly. I ate like 3 or 4, those things were addictive.
What bothered me was what happened a couple of hours later, I had a massive stomach bloat and ache, higher than normal body temperature and generally felt like I was gonna throw it up and I couldn't hold it. After an hour of lying in the sofa I said that it was enough and indeed, threw up my dinner that night.
To my list of things I don't eat, xylitol was added inmediatly, I have never felt so sick, so fast in so little time.
>But the code examples are in Java and C++ and I do python/JavaScript/ruby/
The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your class", or "think about all the ORM code that you use". None! I use none of that!. And I can't even call any tests because I can't extend a non existant class, there's no objects in here!.
The author also says:
>You need feedback. Automated feedback is the best. Thus, this is the first thing you need to do: write the tests.
I don't need automated feedback. I need to untangle this deep business layer that everything is wrapped around in a 40 years old codebase, with practically no documentation and having to modify one of the core systems of the company. Sometimes I can't even trust the feedback the program outputs. In this kind of scenarios where the code is so messy and limited by technical factors, the best approach I have found is to debug. And that's it. Follow the trail, find the "seam", and then start your kingdom in the little space you can. Because if you tell your boss that you are implementing Unit tests in a 40 years old codebase, the first question he is gonna hit you with is "Why?", and the article doesn't give any compelling argument to answer this.