Designing New Features

Hey everyone! Today, I thought I’d give you a small peek into one aspect of our development process: designing new features, and making sure that those features don’t cause unforeseen problems. Today, I’ll be using one of our biggest recent releases as an example: EDGE EDT bi-directional integration. Single-directional integrations, such as TPW, have only one side (the EDGE) send data to the other (Punchmark) and are relatively simple. If we see new data on the website uploaded from the EDGE, we make those changes on our end, and that’s about it. But some interesting issues come up when you allow both sides to send data back and forth.

Let’s say you have a store with two locations, and the only way to manage inventory between them is by calling the other store with changes you make. In most cases, this is fine. But what happens, for instance, if both stores decide to put a piece on sale at the same time, but for different amounts? Each store calls the other to let them know of the price change, each store updates to the other store’s price, and now you have two different prices for the same piece! In the tech world, this is called data fragmentation, and it’s one of our biggest hurdles. When we design a two-way integration, we have to account for the potential of data fragmentation between the EDGE and Punchmark so that your data is always the same in your POS system and your website.

So how do we solve this issue? One of the easiest things we can do is to simply compare the exact times that the changes were made. If we go back to our analogy, both stores could tell the other not only the new price, but also the precise time that they updated the piece. This way, we can always use the newest value, and ignore an update if it's older than the one we currently have. Additional data can also be passed along about the way the piece was edited, with both sides agreeing on a set of rules that are used to determine which set of data is correct. There are lots of potential ways that data can become fragmented, so the rules used get equally complex.

I hope you enjoyed this peek into how our dev team solves problems! If you want to hear more about this, or if there’s anything else you want to know about our technology, let me know in the comments and I may write a future dev blog about your topic!