3 ms·

This is all fine but... the rest of the world is not freezed. Let's say you are happily mantaining a stable, boring ERP app for your... cigarette lighters plant

by Pamar 3y ago

This is all fine but... the rest of the world is not freezed. Let's say you are happily mantaining a stable, boring ERP app for your... cigarette lighters plant. Out of the blue, one of your main suppliers declares they will accept orders only through a REST interface starting next quarter. And that you can/must use it to track your orders, instead of sending an email to one of their employees. One week later, you are required to provide invoices in PDF instead of just printing on paper. And your accounting system will switch to Oracle Finance in October... Your ERP was developed on Progress ABL, and nobody really cared to port the old code to a web-based architecture because it was just for "internal use" and Putty was fine.

throw310822 3y ago
I've worked for a small company that does an old boring ERP. In C. The oldest files in the library date to the late '80s. The whole thing runs on a dime, is super fast, and a few developers could manage the needs of tens of clients. Implementing orders in REST was probably done in a couple of weeks of work. PDFs have been there since ever.
- noduerme 3y ago
  This too. If the foundation is solid, it's easy to shift the outputs.
noduerme 3y ago
Well, I can't tell you how many dozens of times I've had to learn some stupid company's API and integrate it into software just because a client decided to do business with them. That comes with the territory, and you set up whatever you need to make it work. When it happens, it's a sprint, and you migrate everything you need to. But that's very different than migrating it because you're bored or want to sell the client a new shiny thing.
- Pamar 3y ago
  Of course, but I was just trying to explain that sometimes you are forced to innovate due to external interfaces/dependencies. And maybe these were introduced in other companies because their IT depts. are run by "fashion of the month", but whatever the reason, you now have a problem. And if your sw and your skillset has remained frozen in jade since the early 90s... this will be painful and probably require at least one false start before getting it to work reliably. I have noted a tendency in people who work always on "very stable" technologies to go in crisis mode as soon they have to (for example) produce a file in XML or JSON format after 2 decades of CSVs... this unfortunately almost routinely ends in stuff which is very brittle ("XSD? you do not understand, we need to produce an XML, ... I dunno what an XSD is or has to do with this requirement - except that they both start with an X, maybe - so please do not make things unnecessarily complicated and just go back to coding, we were supposed to start testing one week ago.")

by Pamar 3y ago

throw310822 3y ago

I've worked for a small company that does an old boring ERP. In C. The oldest files in the library date to the late '80s. The whole thing runs on a dime, is super fast, and a few developers could manage the needs of tens of clients. Implementing orders in REST was probably done in a couple of weeks of work. PDFs have been there since ever.

noduerme 3y ago
This too. If the foundation is solid, it's easy to shift the outputs.

noduerme 3y ago

Well, I can't tell you how many dozens of times I've had to learn some stupid company's API and integrate it into software just because a client decided to do business with them. That comes with the territory, and you set up whatever you need to make it work. When it happens, it's a sprint, and you migrate everything you need to. But that's very different than migrating it because you're bored or want to sell the client a new shiny thing.

Pamar 3y ago
Of course, but I was just trying to explain that sometimes you are forced to innovate due to external interfaces/dependencies. And maybe these were introduced in other companies because their IT depts. are run by "fashion of the month", but whatever the reason, you now have a problem. And if your sw and your skillset has remained frozen in jade since the early 90s... this will be painful and probably require at least one false start before getting it to work reliably. I have noted a tendency in people who work always on "very stable" technologies to go in crisis mode as soon they have to (for example) produce a file in XML or JSON format after 2 decades of CSVs... this unfortunately almost routinely ends in stuff which is very brittle ("XSD? you do not understand, we need to produce an XML, ... I dunno what an XSD is or has to do with this requirement - except that they both start with an X, maybe - so please do not make things unnecessarily complicated and just go back to coding, we were supposed to start testing one week ago.")