Walkenhorst’s: Building a Custom Tool to Replace Warehouse Scanning Software

About Walkenhorst's

Walkenhorst's makes sending packages to inmates incarcerated in correctional facilities easy. As a family-owned business, they run two independent warehouses and stock thousands of items for their webstore. Planet Argon started working with Walkenhorst's in 2022, as their team began to look for developers who could support them better in their operating hours. This work primarily took place in their Ruby on Rails applications, which utilized Spree to handle orders, display products, and manage a lot of location information.

The Request

Build an application that could be used on handheld scanner devices in the warehouse. This application would utilize the existing database and processing jobs Walkenhorst's had already invested in to help users perform actions like putting away stock, picking items for an order, and generating reports on stock levels.

There were a few big factors for the request we needed to consider:

1. The existing dataset was currently running in a Microsoft SQL Server database.
2. The handheld devices would run on an Android operating system, utilizing a touch screen for navigation and a barcode scanner for most data input into fields.
3. The application's deployment would need to interact with an on-premise server in each warehouse, requiring coordination to bring new changes into the warehouse's live environment after a push.

Planning & Discovery

To get this project off on the right foot, we met with Josh at Walkenhorst's to understand how the different modules of the application would work with the database and the handheld scanners. Some critical questions going into the planning for development were:

• What did you like about the previous iteration of the handheld scanner's interface?
• Where is the data stored now?
• How many users would be active simultaneously on any given day?

In the discovery phase, the development team explored a few options for building the frontend and backend services and ultimately decided to use a Bootstrap JS as a frontend framework with a Rails backend. Due to the isolated nature of the database and devices, which would run on a local Wi-Fi network, there were no external APIs or other applications to consider when designing the application infrastructure.

The Risks

With any project, you can identify several risks upfront in the planning process. For the scanner application, we knew the database we would aim to deploy to at the end of the project was going to be a physical database at the warehouse location. We also knew this server would be running on a Microsoft SQL Server environment and maintained by the local representatives on-premise once the application was finished.

As a development team that works primarily with Linux cloud-based operating systems for servers, we had to consider a Microsoft SQL Server OS when structuring how the application sent and received data. (Spoilers: we also needed to make some performance considerations at this step!)

The Approach

We approached the work in a 2-week sprint-based model to provide the most flexibility to this project. Starting with a spike of work, the first goal was to set up the infrastructure that the development team would need to build the application on top of – examining the data, setting up a staging server environment, and getting to know more about the target devices.

Starting with a spike of work is a great way to dive into a project and solidify a more realistic project estimate, especially when working with a new application or in a project where only some pieces have been clearly identified.

After the spike of work, the project was planned using a Sprint-based model with phases. Each phase would contain several sprints to build towards a minimum viable product (MVP). After each phase, work would pause for a few weeks as the MVP was tested in the field with the actual devices. This way, real users could put the application through its paces and provide some insights on how it felt to complete tasks with it in their hands.

The Project

This project was planned in three distinct phases, each with their own goal in mind. In the original plan, the third phase was smaller and reserved for implementation and iteration as the application went out to the local warehouses in its near-final form.

In the end, Planet Argon completed fourteen sprints primarily based on the different modules the application needed for daily function. In the original plan, ten sprints were outlined. As the project got rolling, Walkenhorst's was able to see the different implementations live in the warehouses after a phase was complete, which allowed for a lot of minor adjustments such as enlarging buttons for people who were using gloves, extending the session length of a login, and abbreviating some longer text fields for item names. During this process, Walkenhorst's team also identified a few extra modules to add to the original plan, which would help them with things like reporting and stock leveling.

Going Live 🚀

The last big module was rolled out to the live warehouse servers at the end of Sprint 14, almost exactly one year after the project started. As this project was implemented in phases, the core functionality was already live in the warehouses by the time we pushed out the last feature improvements.

One issue discovered as the entire workforce began to test the application in a real-world capacity was that simultaneous calls to specific jobs in the database were sometimes taking a long time to complete or timing out. The resolution to this was a bug in the application related to which database was being used as the primary database for on-premise queries that didn't become obvious until we hit a certain threshold of simultaneous queries. This was quickly resolved, and everything is running super smoothly now!

Reflecting on the Project

In future projects with existing database procedures, the team highlighted that they would like to be involved in helping to diagram the different connections between a user's journey and the database procedure performing actions. This would have helped better understand the data returned from the database, which was displayed on the front end of the application (sometimes incorrectly).

We were lucky in our case that Josh with Walkenhorst's was intimately familiar and open about the structure of these procedures. But that's not always the case!