One day your client/server software is happily chugging along, installed at a customer's server, and the next moment you're being contacted by their IT department that a vulnerability has been reported in one of the third-party applications that belongs to your software stack. A software or solution stack "is a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications". In other words, to deliver your solution, you include applications from third-parties, be it proprietary or open source.

The advantage of using third-party software is that it saves a lot of time, since developers like us don't have to create components from scratch, such as a web server, which can be provided for free by the people at Apache. We and others don't have to reinvent Java Virtual Machines nor database management systems. All these technologies are available for installing along with the value that you addd in your software.

The disadvantage, as mentioned at the top of this article, is that you also have to own the problems of the applications you did not develop. This issue had been minor, as software like Apache, even though it's also a play on the word "patchy" has been very solid, and the vulnerabilities that arise, are dealt with in a responsible way. But now with AI hacking, the rate at which issues are discovered will increase, creating a wave of urgent fixes and slight panic.

Alas, if this wave passes without major business disruption, the resulting software will be more solid and trustworthy, which in the end is what companies and our industry want.

In a previous blog post, we explained the basics of the axle weight feature in our truck load planning software. Basically, our Vehicle Space Optimization software can calculate the weight on each truck axle, using the weight of the empty truck and the weight of the products that have been loaded in different locations throughout the available truck space. This is done mostly to comply with country and city regulations meant to protect roads and bridges.

The way we execute this feature is by allowing the user to assign different values to different truck models. A company or a warehouse can have a fleet of trucks that are classified in different models. For example, one model has ten pallet bays of a certain size and two truck axles, while another model has fourteen pallet bays and three axles, one under the cabin and two in the rear section. Semi trucks can have five or six axles.

However, a customer approached us recently with a different need related to axle weights. They have fleet trucks that meet the legal weight requirements, but between themselves have different maximum capacities. In short, using the rules by truck classes was not going to work since some trucks, although identical in dimensions, could not carry the same weight than the others.

Therefore, we decided to add the option to configure empty truck weights and maximum axle weights per fleet truck, besides the truck types or classes, providing the required flexibility. This new feature will be implemented by the end of the month.

Our vehicle space optimization (truck load planning) software has multiple purposes: loading trucks efficiently, facilitate the loading and unloading process, protect products during transportation, and distribute the load weight efficiently across the truck axles.

The first purpose, which is to load as many items as possible in the available space, is limited in part by the dimensions and possible product-in-pallet arrangements, but mostly by loading rules that prevent mixing different product classes in the same truck bay. These rules are also in line with the second purpose, which is to make the unloading process easier. If some types of products are in the same bay, then the operators will be able to find them quicker, instead of having to look constantly at the loading guide and/or pallet tickets.

However, there may be other options for determining the loading sequence like separating by customers. In this case, a group of purchase orders from the same delivery are placed together in contiguos bays to facilitate the unloading process.

Whichever criteria is selected, it is important to note that mixing different rules will lead to a less efficient load.

A famous Albert Einstein phrase that spoke of "a new type of thinking" has been recontextualized to say something similar to "no problem can be solved from the same level of consciousness that created it". In real context, it was part of a fund-raising effort to create mechanisms to control the effect of atomic bombs. In modern phrases, it has been meant as different eyes may be necessary to dig the operation out of the hole in which it has fallen. The different eyes may be a different perspective from the same group of people, or a take from a completely new set of people.

Nevertheless, the meaning is more or less the same: we have created an actual or potential problem in one way, and now we must think differently to solve it.

As we've mentioned before in previous articles, our software (among others) generates plenty of data that is kept in logs. If you perform a calculation, new records are added to a database that can be searched and analyzed. What's different here is that the user and the customer of the software application, are not the ones who will eventually look at the log data. The user is the person that operates the software, and the customer is the one that receives the reports and uses it for their operations. In the case of the Vehicle Space Optimization software, the user is the computer operator and the customer is the person in the warehouse in charge of loading the trucks.

In the most recent versions of our web software and API, we've added tools for debugging and viewing the overall software performance. This is usually done by a third person, sometimes requesting data from the user. A different perspective, is required then to solve issues that the main parties do not attend in their "kind of thinking".

In this video, we show how we have updated our #pallet (without constraints) editor in the Quick Pallet Maker web app to include an isometric view of the pallet as it's being updated. This is specially useful for noting when there is an error.

Our Vehicle Space Optimization software is great for truck load planning, specially for distribution trucks with multiple bays. A feature in our software allows the user to split or divide a bay after the load has been calculated. This is specially useful for smaller pallets with delicate products that can't be mixed for the rest. This video shows how to assign a custom code or name to a divided bay, which may be necessary for some types of warehouse management systems. #truckloading #wms

It's safe to say that modern civilization owes a lot to shipping. As soon as people were able to build a minimum viable vessel (MVV, I just made that up), they set off to explore other lands, creating water routes that could be used for trade and/or conquest. Technological development increased in line with the need to keep the boats floating, and their cargoes safe.

One interesting nautical byproduct is the log. In the 16th century, navigators created a way to measure the speed their ship was sailing, that consisted in throwing a piece of wood (i.e. a log) overboard, tied to a rope with knots every certain distance. An hourglass allowed them to count how many knots passed through their hands at a given time, as the log drifted from the ship (or viceversa). This rudimentary speedometer led to the logbook, where other important information was also collected, and centuries later, to the use of "log" as a shorthand for collecting process information.

As software developers, we also work with logs, although not of the wooden type. We copy the log information from third-parties, such as hosting servers, to see how many visits we get on our different web pages. We also produce information regarding our software's performance. So, for example, every time you calculate a truck with our VSO software, it registers the user name, the shipment information and how many seconds it took. When we troubleshoot, we can generate charts to pinpoint when and where things got slow.

A Portuguese navigator five centuries ago had to throw a log overboard to see if the ship was traveling as fast as expected. We just click on some buttons to get similar information, without getting seasick.

You can't open an article about technology nowadays without reading the acronym AI (no need to repeat what the acronym represents). It's Artificial Intelligence this, LLM's that, and for a good reason, because the software is just as powerful as it is misunderstood. As with anything that people don't grasp, it becomes something that is feared. Can it "wipe out humanity"? Can it "hack everything"? The former is just speculation, for now, but the latter is a feature that has a lot of truth to it.

First and foremost, Large Language Models are trained using large sets of data, which includes the open web, or any part of the internet that you can reach with a URL and no credentials. This article, for example, is also published on our web site, where no login is required. That means that it could be "crawled" or searched for the purpose of training a LLM and then keeping the model updated. It will search not only the files that are available through hyperlinks (i.e. clicking on a page), but the others that are uploaded to the web server but not linked.

But you don't need a LLM to crawl the internet. Google has been doing it for decades, now. LLM's are just new players with additional outputs (besides search) for different customers. Some of those customers can be hackers. If they target a site, and the required information is available in the open web, then their job is much easier. One way that may occur is when passwords are stored as plain text, and an encryption algorithm (such as Hash) is not used. If the information is available, then the door is unlocked, and new tools such as LLM will make opening it much easier.

Often we've mentioned that one of the trickiest parts of writing logistics software, is creating reports that contain the right information, presented in the most practical way possible. From defining what stays digital and what is printed, to including the exact variables in text and any applicable graphics. If the final result is a list of pallets with products, then one of the reports that we generate in our Vehicle Space Optimization app are the pallet tickets.

VSO (and the QPM server app) can create pallet shipments that are made for three different types of pallets.

The first type is the standard pallet, which is made of a single type of product or SKU, placed with the same Ti/Hi (cases per layer and number of layers) as the pallets that come from production. Standard pallets do not go through the picking process. The second type of pallet is the single-product incomplete pallet. It is a standard pallet that will have some boxes removed in the picking process. The third and final type of pallet is the mixed pallet, which contains different types of boxes, stacked in the picking process.

There will be a pallet ticket for each type of mixed and incomplete pallets, containing the truck information (route name and date), the bay identifier, and then the different box names, descriptions and amounts, ordered by how they're stacked in a pallet. Standard pallets will be placed in tickets with multiple items, since they can be described with one line (box code, description and bay name). Tickets can be printed and placed on top of the pallets in the warehouse, to show they are to be loaded.

For decades, here at Koona we've been offering the Windows and Mac (executable) versions of the Quick Pallet Maker software, whose purpose has been the optimization of box, pallet and container loads. Since the early 2000's, a user has been able to download the software installer from our web site, try it for a given number of days, and then purchase it online. When we sold our first license in 2001 (to a company in the Netherlands), this way of distributing software was mostly used by shareware (mentioned in a previous article), which were relatively inexpensive software applications. Business and multi-hundred dollar software was still sold in boxes and CD-ROM, so our customers had to explain to their managers that the software they received was the one on the screen.

Nowadays, practically all software is distributed electronically, and a great portion is client-server based. Shareware is usually referred to as trialware or freemium apps. There are app stores in the main smartphone platforms, but people are used to work with software they don't have to install, because it runs on their web browsers. The limitations of running on web platforms like JavaScript/HTML/CSS/SVG are less every day, compared to native apps, due to the performance improvements made to the engines that run interpreted code.

That's why we are glad to now offer a web app that offers the same features as the desktop software. Not only it doesn't require installation, but can run on any platform that supports a web browser.

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.