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.
Would you be so lucky if your legacy code was written in a well-known language. At a previous employer we had a big pile code in a “macro” language. It could interface with the main C++ code base. It was similar to assembly language in that it had no loops (just gotos) and register-like local variables (no custom names, just L0, L1, L2,…). The semantics were weird, something like unexpected pass-value-value versus pass-by-reference behavior when calling functions.
One customer required lengthy qualification processes when changing the software. But “configuration changes” had a lower bar and somehow these “macros” counted as config. So eventually all the interesting business logic and RPC processing end up in a giant macro file.
Sounds similar to, but not as bletcherous as, BANCStar, a famed "esolang" that was really the output of a form generation tool used in the finance industry in the 90s. Some engineers figured out that the form generator's output was actually expressed in a Turing-complete, though very arcane, notation replete with opcodes and operands, reverse-engineered it, and started working directly in this language without using the tool to do more sophisticated things than the tool enabled on its own. The boss man probably said "Great! When can we put this into production?" and it's been downhill since.
Relatedly, a long time ago I discovered that Zenographics Mirage—a vector graphics/illustration program originally designed to run on like, VAXen, with both a text terminal and a graphics terminal with a digitizing tablet (similar to this setup seen on Reading Rainbow: https://www.youtube.com/watch?v=b_zYaIxb6dY&t=965s), but later ported to PCs—ran on a sort of bytecode. There were a number of sample scripts shipped with the package that allowed you to automate things in Mirage's command language. Some of them had statements like DO 62,2,32472,32476,0 and comments that read "Don't worry about this, this is just Mirage assembly language." Intrigued, I discovered in the manual a feature you could enable called Op Code Monitor that flashed similar numbers whenever you entered a command. It was mentioned but not documented in detail, nor what the numbers meant, but from that and the scripts I could make some pretty good guesses. I figured out how to make Mirage prompt for a point and store it in a register; and with that I made a command to draw a rectangle that could be rotated. A rectangle in Mirage was defined by its corner points, so when you attempted to rotate it it just rotated the corner points and drew an axis-aligned rectangle with the new corner points. My command accepted two corner points and drew a polyline, so that when you rotated it, the whole rectangle rotated.
From personal experience with bosses: no, often times it's not a sufficient argument.
If the choice is thought to be between:
* delivering value directly to the customer to justify a company's existence
* or adding tests to things that already work (shore up) in an effort to make more correct changes in the future
Will anyone be surprised how often it's the former that management will go for?
I've found the appetite for this type of testability/observability improvement work increases proportionally with the number of support calls being made from customers complaining about the current feature set being unstable and buggy. This work is less palatable when customers really are just looking for that next new feature you promised instead and everything else is a-ok. The exception being things like orbital navigation systems etc..
That's because you're not opening Jira tickets titled Refactor Foobar. You're just doing it as a consequence of resolving real business issues. I have seen developers, and once been the developer, suggesting a refactor to the PM. That rarely works: it does not (directly) address a business goal.
I read the book shortly after it came out, when I was working on an enormous system of legacy code. Unfortunately, I didn't find the book particularly helpful in terms of strategies for understanding or modifying legacy code. Yes, tests are a good thing, but I expected the book to provide a lot more.
I agree with the parent comment that it is useful to follow the "trail" through the code. It can be a big effort just to figure out how the pieces are connected. Figuring out the data structures and files is another important thing. Also, write documentation as you go; this will help others understand the big picture. If you can just jump in and start writing meaningful unit tests, your legacy system is kinda trivial :-)
Overall, there are people who view testing as a useful tool and people who view testing as an ideology. This book falls into the latter category.
I've skimmed the source material and it doesn't either except for the general advice of putting it all in some kind of conceptual box and slowly move parts to modern or better managed solutions as you try to reverse engineer it all. The underlying subtext was that it is all probably worse than you think and there isn't much good news... But "containment" in various forms is the direction forward mostly unfortunately.
> And I can't even call any tests because I can't extend a non existant class, there's no objects in here!.
I'm gonna preach for the church of "away with unit tests": so what? You don't want to test code. Code is not what the user care about.
You want to test behavior. And for this you don't need to extend classes. You should not have to rewrite any code from your application. Like you say: write tests at the seam. Automate user inputs and checking outputs.
A good test suite should not need to be rewritten during refactoring. It should even allow you to change language or replace for an off-the-shelf solution you did not write. If a unit test suite does not allow that, unit tests are an impediment. And I don't care about the "test pyramid", like the IRL ones, it is just a relic; from an age when launching all your tests in parallel was unfathomable.
> You don't want to test code. You want to test behavior. A good test suite should not need to be rewritten during refactoring.
100% agreed.
> I'm gonna preach for the church of "away with unit tests"
I disagree with the semantics here.
From the article: "In short, your test is not unit if it doesn’t run fast or it talks to the Infrastructure (e.g. a database, the network"
This says _nothing_ about what part of the app structure you test. It's not always a class-method test. Outside-in, behaviour centric tests that are not close-coupled to structure, can also be unit tests. And most of the time, it's a better kind of unit test.
Kent Beck said many times: "tests should be coupled to the behavior of code and decoupled from the structure of code."
"test behavior" was the original intent of unit tests. The idea that unit tests are only close-coupled class-method tests, or that testing 2 collaborating classes from the same app at once counts as an "integration test" is a latter-day misconception. A dumbing down.
You ban them from coming back in after a few warnings. Stores seem really icy about facial recognition right now though. The optics are pretty bad (a play on words pun?)
There have been a few stores that won't really stop people from coming back, they just quietly file charges, and then the person finds out next time they get pulled over or something along those lines.
Use your army of lawyers to help file misdemeanor theft charges of course. Then get one out of 100 of the defendants who actually has something to lose to pay big damages to fund it to happen again the next time.
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.
In my experience they're also a bit particular about declaring things as they are on the border.
An oil platform getting towed into place is one piece, not an IKEA kit or similar.
That said, could very well be the local customs officer was just totally unprepared and this was the solution they came up with on the spot. I've seen other cases where different companies have gotten directly contradictory instructions from different customs offices on the exact same scenario.
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.
>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.
Xylitol is not an artificial sweetener, it's a sugar alcohol. Sugar alcohols are generally derived by processing natural ingredients. Xylitol is made by extracting the sugar alcohol from beech wood. Sugar alcohols can cause bloating and diarrhea due to osmotic effects [1] and can have laxative properties for some. I'm a bit sensitive to sugar alcohols myself.
Look I don't think this kind of comment adds any value to this discussion. There's a linked paper here and it's useful to discuss it. But humans all eat food, and if we start chiming into every nutrition article with random anecdotes about what we eat, then the purpose of keeping HN a high quality site goes away. The science is hard enough to get straight, adding random anecdotes lowers whatever signal we have.
We were affected by the downtime, suddenly our VPNs went down and we started troubleshooting if it was a switch sudden reboot, a physical problem, anything. Odd for some of our VPNs to randomly shut down rejecting all traffic but just at the endpoint. Then we started having some very specific problems with just some FTP addresses and couldn't figure out what was happening.
Until our CIO went to the bathroom and came back saying "Hey, these websites aren't working from our WIFI network but they're working fine from mobile data? Could it be a navigation problem from Orange?"
>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.