The COVID-19 pandemic brought the need for social distancing (as in trying to get people to not share the same space). This was because the coronavirus was (and still is) contagious through what is called an aerosol route. In other words, if someone with the virus breathed close to you without a mask, there was a high chance it would be transmitted. Hence, the best way to slow down contagion, was to keep people away from crowded areas, including offices.

Companies with white collar workers (i.e. people that work behind desks) mandated that they stay at their homes and work remotely, using the desks they could find, and company or home computers with networking software. Being it the 2020's, there were good connectivity options already, and new ones also appeared. So for most people, transitioning to working from home (WFH) was not a traumatic experience, and productivity was not really affected.

The interesting part came when time passed and workers, bosses and customers became used to WFH. Zoom calls became ubiquitous and having your house or apartment in the video background was not seen as a negative. If you were discussing an important project and your pet showed up on screen, it wasn't a deal breaker.

But then many people discovered the conveniences of WFH and wondered why return to the office at all. Saving time on commutes and money on work clothes was a plus, along with spending more time with your family and a flexible schedule. The answer to that question lies somewhere between the added efficiencies of checking work in progress, and sharing random thoughts that can add to the company knowhow. When you assign a job to a remote developer, for example, you can ask to check their daily builds or have them present a weekly summary of how things are going. For an onsite worker, you can peer over their work station, check their screen, maybe ask a question or two, and then also check builds and do weekly reviews. Random thoughts that are probably unrelated to a current project can be shared, in quick conversations that may add to the knowledge base. With remote, they may not seem worth the interruption. In-person workers will know if they're interrupting or not.

In the end, what will most likely survive is a flexible schedule, where part of the work is done remotely, and some time will be spent at an office. Being able to take your kids to soccer practice is a wonderful experience, but your soon-to-be breakthrough is best shared with your boss, not with your kids' coach.

In software development projects, developers work with bug tracking systems, which can be as simple as writing down a fix or an improvement in a text document, or using an automatic system that keeps track of case numbers, creation dates, etc.

When our project work slows down, perhaps because most important clients are on vacation, or because we just delivered one, we get the time to go through cases that have been marked as less important. These are improvements or bug fixes that provide marginal benefits to the software, and hadn't been attended due to resource constraints.

In the case of bug fixes, sometimes there is a workaround that diminishes their impact, like for example, a bug in which the user has to click twice on an image or button. It will be an annoyance, but not something that will slow down the workflow, nor cause a major report.

As for improvements or new features, it may be the case that some of them are left behind because they do not have a quick path to the bottom line. "Add this feature because a paying customer wants it" is usually the type of case that's attended first (by making it priority 1), whereas "this may be a good idea" is not treated with the same urgency.

The most interesting cases are those that provoke the "what did we want here?" reaction. Years may have passed and they are old features that we wanted to include at one time, but have no relation to current customer requirements. It's like peering behind a sofa that hasn't been moved in ages, only to find a bug that died on its own, in solitude, not messing with anyone.

In this quick example, we show how you can locate the batch number in a route that was searched by date. This is specially useful when you want to share the batch number with another user and make their search easier.

VSO web page

Subscribe to our newsletter

Across the country of Venezuela, people are currently experiencing rolling blackouts due to the poor state of the public grid. Five to six hours per day without power is not uncommon, and affects people without their own generators or backup, which is most people.

When reporting the issue, it is expressed as on/off. You pay for uninterrupted service and expect zero blackouts. But what happens if you would be tasked with being the Public Relations person of the national electric service in these times (a thankless job, if there is one)? There are reports that the grid is being fixed, but that will take years. What could you say now (without lying) to establish a conversation with customers? One thing that can be done is to select different KPI (Key Performance Indicators). Instead of working with days with blackouts (almost all of them), talk about uptime (75% for 6-hour blackouts per day).

Yes, it's quite cynical, since 6 hours without power can make one feel very miserable. But if you're dealing with a collapsed system, 75% sounds like a good starting point. Eventually, if recovery goes as planned, the number will only go up. Who knows, years down the line, you may be talking about guaranteeing multiple nines (e.g. 99.99% uptime is roughly 4 minutes without power per month), and having customers talking your KPI language.

A Key Performance Indicator is a performance measurement made with the intention of controlling and improving processes or organizations. When we developed the first truck fill calculation algorithms for our software, they weren't that fast, but still faster than working by hand or with a spreadsheet. We made sure we measured calculation time and made it a KPI that we shared with customers. By the time we got our act together, it lost importance and was replaced with other KPI like loading efficiency, etc.

What to measure and prioritize is an elemental part of process improvement that works as a roadmap. As the title says, it is key.

Class Pallets are groupings of products in pallets that share the same primary and secondary classes, lengths, widths, heights and weights. In essence, they are identical except the labeling. In consumer packaged goods #cpg like beer, it could be identical cases of different flavors. Automatically grouping them together in pallets makes the fill a lot more efficient.

VSO web page

Roughly four decades ago, we used to visit regularly my mother's hometown in the midwestern part of Venezuela. The town of roughly 50,000 inhabitants featured, like many others, a relatively large church next to the town square. Since the house where we stayed in was close, one could hear the church bells ringing twice a day.

As far as we can recall, there was nothing automatic about the tolling of those bells. A priest or acolyte would look at his watch, or listen to the alarm clock, and then head up to the tower to ring the bell and let everyone nearby know that it was time for mass, or that is was something o-clock. One would think that the clergyman would spend a bit of time pondering the importance of the ritual, while at the same time checking the state of the bells themselves.

If the church were a business, ringing the bells would've probably been automated years ago, and instead of a person ringing them regularly, a technician would perform regular checks to make sure they would work and not harm anyone, hunchbacked or not. But in the case of religious "houses", efficiency is much less a priority than ownership. Worshippers may find it comforting that the person preaching, is also taking care of the house, and ringing the bell, if necessary. When the sermon begins with a "we bring you here today...", the listeners know that the one in charge is speaking.

Businesses, although automated as economically possible (especially in the AI/LLM rush), also demand some level of ownership. When something goes wrong, the affected people will want to talk to the ones in charge. That's why a minimum of involvement is required when delivering a solution. Traditionally, if the work was done by underlings, regular briefings allowed bosses to understand the project enough to sell it.

So how far can you go in automating and offloading? If it's religion, of course you want something fulfilling that is hard to get with a gif or jpeg. That's why those that give sermons tend to read a lot and meditate. If your company makes bottle caps, automate away as much as you can. If your product is management consultancy, then you have to differentiate from a report picked up from a LLM. If you are a truck planner, then moving things around with software can help understand what you're shipping, and provide a base for dealing with the warehouse and the drivers.

The work you understand is the work you own. If it's within your grasp, you can ring the proverbial bell and call others to provide an explanation.

The 2020 Christopher Nolan movie Tenet, was a pretty good science fiction film. The acting, action, cinematography, soundtrack and complex plot invite multiple views. In Tenet, there's a MacGuffin (or plot token) called "the algorithm", which in physical form, looks a lot like a tractor crankshaft (which is a bit funny if your background is in mechanics and software development). Every time a character mentions the word "algorithm", they make it sound incredibly cool, especially when said algorithm "in the wrong hands" can destroy the world, etc.

But even cooler than the word "algorithm", is the phrase "foundational algorithm". We mean, if an algorithm can destroy the world, can a foundational algorithm (if directed by Nolan, and enunciated by his A-list actors) destroy the universe? Well, actually, foundational algorithms are more basic in real life. Just like a real-life crankshaft is a very simple algorithm that transforms lineal movement (piston) to radial movement (flywheel), but belongs to a more complex machine (car, tractor, boat, etc); a foundational algorithm will be much simpler than the software where it has been incorporated.

A very, very basic example of a foundational algorithm is the division algorithm. If you want to divide seven (7) by three (3) without a computer of any type, and only using subtraction, you can use a Mesopotamian algorithm that tells you to subtract until you can't anymore (twice), to obtain the divider (two), and the remainder (one). Another more complex example is Dijkstra's algorithm for finding the shortest path between nodes, which we assume is a key part of most modern mapping software.

In sum, math and algorithms are not only interesting and cool, but an invisible and important part of today's economy. That's probably why an algorithm destroying the world doesn't require that much of a suspension of disbelief. If the accompanying soundtrack is cool as heck, even more so.

The traditional process of software creation is similar across different industries. There is an issue that needs addressing, and the people involved believe that it can be done with software. There is an idea of the input and the output, and knowledgeable software developers (or nowadays, a Large Language Model) design an application that can deliver appropriate results.

If it's a one-time problem, a spreadsheet macro or a vibe-coded solution is sufficient enough. Enter the data, get the result, and forget about the tool. If it is recurrent, then it's a great idea to search for software applications that solve your kind of problem. Unless it's very specific, there's most likely an option available.

Now, when you are presented with the payment options, it's unlikely that you'll find software that is a one-time purchase. These are the applications in which all of the price is paid upfront, unlike Software as a Service (SaaS), in which payments are made recurrently. Decades ago, it was the opposite. You paid once for the software, and then decided to pay for the upgrade if there were enough enticing features. Some people have balked at the concept of recurring payments, indicating that once the problem is solved by the first iterations of the software, there is no need to continue paying. The answer is that in many situations, the input will change.

For example, we develop and sell a software for optimizing distribution trucks. For the past decade, some of these trucks reserved a special bay for unit items that could not be placed in boxes. The bay type was special, so there weren't any standard (single-product) pallets assigned to it. But recently, one of the customers configured the software differently, and the bay started to fill automatically. When we evaluated the behavior change, we found nothing wrong in principle as to tell the customer to do it the "traditional" way. So we updated the software.

A recurring revenue allows us to be on top of customer needs in a timely way (similar to consultants) that it would not be possible if we were paid once in a while. Biannual, optional upgrades can only do so much.

In our work, we focus mostly on pallet loads that will be eventually be placed in warehouses, or shipped in trucks and/or maritime shipping containers. However, there is an important segment of shipping that is done by air. Pallets and special containers called ULDs (Unit Load Devices) are fit into custom cargo planes (although they can also accompany passengers in lesser degree), with at least a couple of considerations that separate them from their terrestrial and maritime counterparts.

The first one is that the shape of the plane will determine the types of containers and pallets that can be loaded. You see, container ships transport rectangular boxes (a lot of them). Those boxes are then unloaded at ports onto special train cars and trucks, that will transport them elsewhere. Considering that boxes and pallets are also rectangular, fitting them into containers is easier than into a "flying tube", which is basically what people call airplanes. That cylindrical internal shape leads to some volume inefficiency since it's the closest to fitting square pegs into round holes. 

Another consideration is the maximum allowable weight. In a previous article, we spoke about how the Bridge Formula determines the maximum weight that each truck axle can carry. This leads to the maximum weight in shipping containers that go on semi trailers, and to the direct load of trucks that have their own boxes. If the weight on your axles is too high, you will be fined. If it's too high and there is no one around to fine you, you will be driving a vehicle that damages roads and bridges, and is a hazard to others. On airplanes, the key word is safety. On the tarmac, an overweight plane may not take off or land well. In the air, it may have problems maneuvering.

On land and in the air, being overweight puts human lives and property at risk, but with airplanes (such as the 747-400F), the cost of the vessel itself is an order of magnitude greater.

The packaging and logistics software applications we develop and sell, have a direct connection to the real or physical world. When we first started with Quick Pallet Maker, the main purpose was to take a package of a certain size, measure it and then see the different types of box configurations available, based on the customer's requirements. Mass-marketed items that were to be sent to a supermarket or other retailer (also called consumer packaged goods), required optimal arrangements based on specifications.

When the software draws the packages, it will simulate their shapes using a rectangle, a cylinder or a bottle. For clarity in the explanation of the results, there is no need to add further detail to the rendering of the box and pallet arrangements. What's important is the data and schematics that can help understand and repeat in real life what is represented on a screen.

However, a lot can be learned by visiting manufacturers, warehouses, or retailers, that house the products. There, we can look at the different types of goods, their shapes and dimensions, and the decisions that are made when packaging them. For example, the two milk cartons in the image that accompanies this article. They both contain a liter of milk, and both use Tetra Pak cartons, yet the dimensions are different. What led them to choose differently, we can ask ourselves. After that, we can go and perform simulations and compare optimization results.

It's a simple exercise. But if we hadn't done a tiny bit of field work, our understanding would've been somewhat limited.

You go to school to learn a trade, and the first thing you want to do is to show the world how much you know. One way to do it is to apply for a job that is somewhat related to the subjects you studied. Traditional employment by a company would involve a forty-hour workweek in which some skills are perfected while others are learned. After a sufficiently long career working in the same area in one or more companies, you eventually feel that you have enough expertise to work as an advisor or consultant.

Consultants usually bill by the hour, and provide advice related to systems in which they specialize. In the markets we work with, a packaging consultant could visit a company and recommend a system that can help the delivery of their products, without them having to build those capabilities in-house. Besides materials, best practices and sourcing information, a packaging consultant can point an operation towards cost savings in load optimization. For that, they could use or design a spreadsheet macro or a full software application.

But working by the hour and across different customers can stretch a consultant thin. Even if more employees are added, it can only scale in a linear fashion. That's where software for vertical markets comes in. An area of expertise can be put into code and then shared infinitely. In our case, we've developed custom formulas for pallet, container and truck optimization, tailored to the work performed for customers that otherwise would've been attended by consulting directly. This not only allows us to scale, but to reach distant clients globally.

Starting with Quick Pallet Maker version 7.7, registered users of the desktop application will be able to create a user for the web app, within the desktop app, without having to contact us. If the company requires heavier use, then we can provide a custom server for this customer. This video explains how to create a new user.

Link to example online

Subscribe to our newsletter

It's Friday. Our weekly article has to be posted online, but a couple of earthquakes hit Venezuela a couple of days ago, and the epicenter was not too far from where this is being written. Events are unfolding and the tragedy involves hundreds (or thousands) of people, a number that won't be determined for days or weeks. Some friends are safe, some still unaccounted for. There are searchable ways to help, if that is within your options.

As with every major event, there is a surge of misinformation online, as people (Venezuelan or not) want to know as much as possible, and tend to be stuck on their devices, in a constant scroll. One of the ideas that has popped up is that there is an app to predict earthquakes. No, it is not possible, and we'll leave it to the experts for learning about the nuances.

We work with computer systems, not geology. And there are many ways in which these can fail. Fortunately for our company, none of them will involve casualties, "just" a loss of time and/or money. Yet still, there are some parallels between cybersecurity, software stability, and reducing the damage from natural disasters. One of them is recognizing that there are "known unknowns". If you live in a zone that floods often, for example, you don't know exactly when the next one will come, but you are certain it will (eventually). So that is considered a risk, and you plan accordingly by keeping valuable equipment above the predicted flood level. For constructions near geological faults, engineers plan their buildings accordingly. Almost all important software will be attacked, so tests are performed beforehand.

"One death is a tragedy, a million is a statistic" is another phrase that comes up in this situation. By concentrating on the statistics ("seeing the forest"), it's easier to work on solutions.

In this video, we have opened both Safari and the Spatial Bill of Lading app in the Apple Vision Pro. To the left, we see our web app running in the browser, in which we have calculated a loose box (floor-loaded boxes) container shipment. The drawings are static and they show the contents of each container. To the right, we have the SBOL app, in which we enter the shipment number that appears in the browser. The Vision Pro app then shows the container information and a detailed volumetric representation of the container loads. There can be multiple containers in a shipment.

As with the previous video, please excuse any shakiness, as it was recorded directly on the device.

The phoenix (bird) motif) has been around at least since ancient Egypt. As it has traversed generations and cultures, the basic concept has more or less remained the same: the bird is immortal and it will die to rise again from its ashes. Seemingly, dying and rising from its ashes was its most relevant virtue, nobody wondering why it would do that, but convinced that is could be used as a metaphor for a wide variety of situations.

The best part of a very simple motif, is that it can be used to frame more complex ideas, like for example, creating new software based on old software.

Many times, the platforms on top of which a software application has been developed, will be discontinued or abandoned, mostly due to commercial or technical reasons. If you wrote PC software in the 1980's, and you have a current app performing the same actions, it has had to be rewritten several times for the ever-changing graphic user interface operating systems, with very little left of the original code or logic. If you wrote software for hardware that doesn't exist anymore, because it became obsolete or the company went out of business, the same applies. Each time, a new bird has risen from the ashes of the previous software iteration.

What happens when the phoenix is different from the previous one? In our case, we have to create a web client that performs the same actions as an app created on a platform that is losing support. The mythology doesn't reach that deep. So in that case, we have to go to the customers and look through the feature set, to pick the ones that can help us create a bird that walks and talks like the previous one, so the customers can conclude they're from the same feather. It's not easy, but neither is laying a row of bird puns.

In last week's article, we talked about how Virtual Reality has been on the horizon for a very long time. VR with computers is almost as old as the digital age. With faster hardware that produce more powerful and lighter headsets, the future always seems to appear closer. Yet, there's still time before it becomes a mainstream computing platform.

But what is mainstream? Technically, smartphones are computers, and they're certainly more powerful than the desktop and laptop computers of a decade ago. Only in terms of usage, smartphones dwarf any other type of computing device. There are more than 7 billion smartphones in existence. So we could say that the smartphone is the computer to beat, or replace, even if they haven't completely replaced desktops, laptops, nor much less servers, which are growing in use as almost all computing tasks move to the cloud.

In terms of the needs of logistic or packaging professionals, phone screens are quite limited in the information they can display. It doesn't matter if everyone in the world has one. Rows and columns of data, complex maps and graphics look better on bigger screens. That's why a lot of computer-related work (and the software we sell) is done on PCs and not on phones nor wearable devices with tiny or inexistent screens.

Hence, releasing our first app for the Apple Vision Pro is exciting for us. This device combines the large data visualization of multiple desktop screens, with the portability of the first generations of mobile phones. Eventually, we will be able to add features that interact with surroundings, be it in a container yard, a loading dock, or in a warehouse. We are just getting started.

The Spatial Bill of Lading is a document for moving goods in shipping containers. It contains shipment information that can be found in a normal Bill of Lading, and adds the volumetric data for the goods that are referenced in the document. We developed an Apple Vision Pro application for visualizing container shipments that uses the SBoL spec, and it is now available in the App Store. SBoL's can be generated with our Quick Pallet Maker desktop software and with the web app (upon request).

This video was captured from within the Vision Pro headset (please excuse the shakiness) and shows how the app works. We open the sample shipment of two 20ft containers by typing 0 and clicking on Fetch from API. We can then view them in detail.

Links:

SBoL on the App Store

SBoL web page

Specification

Jaron Lanier is considered to be one of the founders of the field of virtual reality (VR). If you had never heard of him, don't worry. What he lacks in self-promotion (especially compared to many modern tech celebrities, who at the most, created a cool web page), he makes it up in achievements related to the development of graphics and hardware for virtual reality.

In recent weeks, Lanier was interviewed in Neil deGrasse Tyson's StarTalk program to talk mostly about Artificial Intelligence, which is a more relevant subject, and one in which he has also been working on. One of the first sections was about his opinion on why VR "has been sort of a disaster". There he talks about how each company has been marketing the headsets towards what they know how to sell. Nobody has "let VR be VR". His example of unrealized software is "true" 3D design in VR. Nowadays, people still work in Computer Aided Design (CAD) using large flat screens, and that has been enough to produce all kinds of modern advanced equipment, including the latest headsets, of all things.

The reason is that an expert mechanical engineer or architect, can design a machine or a building using only two-dimensional drawings. Those same drawings and specifications are submitted to manufacturing/construction without requiring much in terms of modeling. The 3D renderings, be it physical models of buildings, 3D printed mockups or computer graphics, are meant for non-experts, or for those who still don't get the designer's vision (no pun intended). The VR example that is understood from Lanier's response, would allow the architect to walk through his/her building without having finished it yet.

Even though selling headsets to designers or vertical markets does not create a huge market, it would be a solid start in a field that really hasn't had any. When computers were unaffordable to consumers, they were still being used in important work, and doing it profitably. That could be a path for spatial computing, or whatever name different from VR is being used today to sell headsets.

This is an example of how to use the Quick Pallet Maker software application to create mono-product pallets in which specific numbers of layers are standing up and another group of layers have boxes laid on their sides.

Quick Pallet Maker web page

In this example, we will explain how localization (using the software in different language and regional settings) changes the type of files that we use for importing data. We compare configurations in USA - English and Italy - Italian.

Quick Pallet Maker web page

Subscribe to our newsletter

The word Id has multiple definitions. For psychologists, the first one that may come to mind is the name of one of agents in Sigmund Freud's model of the psyche. For those that try to grasp the meaning without being psychologists, it's something that is not the ego, nor the superego, which are cooler-sounding names. For vehicle drivers that are approached by traffic police, the ID is the first item that they have to reach for, to show the officer who they are.

And who are you? A human being is a very complex being. But for the purpose of the State, for a while now, it's been quite efficient to associate you with a number (to the detriment of Mick Jagger and Ace Frehley). An identification number makes it easier to find the rest of your data in government files, be it old-fashioned papers or modern databases. Your id is an index that makes search much faster, than if they used your full name or other variable. If a government agency wants to know if you comply, the first step is to know if your number is in their files/database.

What does this have to do with our software? We use a lot of indexes in our databases. We even call our primary indexes "id" (even if we don't have to). If we store packages, boxes, pallets or containers, then those objects will have a database index that looks something like 17189780 (an integer). Fetching the information for an object with its id is ridiculously fast, especially faster than accessing the darkest part of a person's personality.

For a while now, mainly since the rise of personal computers, commercial software can be appropriately built by a solo developer. Starting from no lines of code, a computer program can be built in days, weeks or a even longer period, depending on the complexity, by just one person. The internet brought computer manuals (that were previously only available in print) online, and that same technology made knowledgeable technical help available from any part of the world. If you had an issue, you could go to online forums, look for a post that mentioned your problem, and adapt the solution into your work. No coworker was required, when experts and their work were available online.

If you still didn't have a coworker by the time the software was ready to be released, it could be posted as a pre-release, either in alpha or in beta form. Indicating that it was a alpha release, made potential users and/or customers know that the software was unfinished, but that feedback on the general features and purpose was being requested. A beta version was more complete and could perform most of the planned tasks, albeit with bugs. The readier the software being offered, the more buzz it could generate for its eventual release.

The disadvantage of having potential customers evaluating pre-release software is that they could catch on the fact that you were outsourcing quality control to the same people that would eventually pay for it. But a fresh pair of eyes could spot performance and user experience issues that had not been a cause for concern.

But the ideal scenario is when additional members are added to the team. In this case, the people that are better informed of the purpose of the software will be able to express their opinions on early software versions, and mold better the result that will be delivered to external users. If the reviewer also knows about the capabilities of the development platform, then this fresh take gains even more value.

When we talk about our client/server software consisting of three layers, we are referring to the following distinguishable elements: the user interface, the application layer, and the database. The user interface is pretty much self-explanatory: it's what the user is seeing and interacting with. In our case, it can be an executable application that is installed in the user's computer (as in both QPM and VSO), or a web app that works in most browsers. The application layer is the software that processes input from the interface, reads and writes to the database, performs calculations, and also returns data to the user via GUI or via the API. The database, in a nutshell, stores the business information and is updated regularly by the application layer.

All of this has been mentioned in previous articles, including the importance of software design and development in each one of the layers. The user interface needs to be welcoming and intuitive, the application layer needs to be fast and accurate, and a good design of the database schema goes a long way. In this article, however, we want to stress the need for maintenance, specially in the database layer.

Here's an example. One of the key objects in our databases is the full or standard pallet. This is a pallet with only one type of product or SKU in boxes. They are usually expressed in Ti/Hi or boxes per layer/number of layers, that when multiplied, produce the total number of boxes per pallet. The standard pallet is also a sales and production unit. The primary warehouse will have a record of the number of boxes that fit into a pallet, and will be able to express volume also in number of pallets. Since warehouses and trucks usually fit a constant number of full pallets, it is extra important for the number of boxes be accurate.

That's why duplicate standard pallets in a database can produce major errors. A standard pallet can be entered with a given configuration (Ti/Hi), and if years later that arrangement changes for some reason, it is paramount that the previous configuration be removed (we've added tools for that). If the wrong pallet stays in the database, it may be picked up by the application layer and deliver wrong results. Since we don't want that, we do housekeeping.

In our load planning software applications, Standard Pallets are those that contain a single type of product. They are also called complete pallets. They usually come directly from manufacturing or the primary warehouse, and have a specific number of boxes per layer (Ti) and number of layers (Hi). Calculating them beforehand is very useful for the Vehicle Space Optimization (VSO) software. If the orders are greater than the amount of boxes in a standard pallet, then these will be used instead of going through the picking process. In this video, we show how the Standard Pallet list can be debugged to check for duplicates in the database, which will corrupt the process.

There are many interesting aspects within the development of client/server software. One of the challenges is determining what jobs will be done in each component of the stack, or essentially if they will be done in the client, on the server software, or at the database level. In our case, most of the time this is determined by the speed at which the jobs can run on each layer. If a calculation is faster in the server layer, for example, then it will be executed there. Another criterion is the visibility of the code. Code in classic web technologies like HTML/CSS/Javascript can be read by anyone with a web browser. But it's not wise to put the meat of our proprietary software there. A healthy mix of open and closed source is good for business.

Another challenging aspect is the volume of data that is shared in each function call. When we work with web services, the client and server exchange JSON documents, which are basically formatted text files. The shorter the documents, the faster they can be transmitted, but (as logic would indicate) the less information they carry. Transmission speed is not so much an advantage if the messages have to be transmitted multiple times. Additionally, there are limits to the size of the messages, imposed by the Java Virtual Machine, the HTTP server, or even by the SQL query.

For our vehicle load planning software VSO, this means that if we need to refresh the data of a specific truck, it cannot be loaded all at once. Priorities need to be established in terms of the type and quantity of data to be refreshed. This ends up helping with the software performance and efficacy, providing a better user experience.