This reminds me of an oft recommended book "Digital Apollo". One of the driving topics is the human interaction component and the difference in designing a fully automated system versus one that is designed with an operator that can intervene. If I recall correctly, the book presents a dichotomy between the rocketeers and pilots (automate entirely and strap people on for a ride vs design a system controlled by a human).
I think they both have their place, but I think acknowledging it as a system design choice is so helpful even in basic business processes (how will I handle exceptions, how will the person remember to handle a rare exception).
I find myself thinking of this problem frequently. We have lots of modern words for it like observability but I think that removes one a bit from the actual problem.
Hey HN! We're a jewelry retailer (~100 mall locations) going through the classic digital transformation story. Our tech stack is built on two endlessly upgraded systems from the 80s (Universe and Magix) that have finally hit EOL. We're modernizing everything - mainly moving to a new ERP (it's a desktop app built in Delphi/Interbase by a third party), plus some in-house stuff. Want to build something? Talk to the users, then build it. Got a better tool in mind? Let's use it. We're running this hybrid on-prem/Azure/AWS setup and trying to get our IaC game going.
What we need:
Someone who's worked with weird tech stacks before and can figure out obscure systems. Experience with retail/accounting is awesome but not required. Must know your way around version control and have strong opinions about your preferred editor for reasons.
Comfortable talking to users and solving their actual problems. Bonus points if you've done multiunit retail before
Some real problems we're tackling:
- Our credit application system is this web app Frankenstein'd together by various devs - it works but the database updates are a mess. Help me fix our autopayments.
- Distribution uses this configurable-but-unfriendly desktop app. Need someone to really get how it's used and make it better - maybe through RPA, maybe just better docs and UI labels.
- Work wherever you want. Occasional visits to Culver City helpful but not required
- Flexible hours (we're PST, but just need some overlap for now - help me fix our async game?)
International = hired through Upwork
If this sounds like your kind of chaos, email me at matt and then a underscore and then pendergraft followed by an at for the main website of the company this is for. Tell me why this interests you and maybe share a cool project you've worked on. Resume optional but helpful.
They were highly patent encumbered for a while. I think much of that is expired but the manufacturing base hasn’t caught up yet.
The pricing is pretty expensive even in bulk. $50 for the larger displays isn’t off by an order of magnitude (e.g. 7 inch with red) especially as a retailer is buying that as a larger solution which includes all the syncing hardware, maintenance programs, and integrations.
For retailers, the savings story is in increased pricing accuracy and reduced labor for price changes. There is the promise of dynamic pricing but that’s a minefield for various reasons.
That’s why you tend to see it in high-value retailers (pricing accuracy, precision, smaller tag count) and grocers (lots of price changes, high labor costs).
You're paying the tax at some point, but if that's at the start of the project it might be high enough to stop it in its tracks. A mature Rails or Django project require abstracting configuration later on in development which is a different sort of tax.
Convention over configuration absolutely has it's perils. I've unfortunately (fortunately?) hit this enough times with Clojure, I know the ecosystem well-enough I'd personally pick composition for a personal project. In a team project where composition makes collaboration difficult (generally a communication and experience problem) I'd probably choose another language with an opinionated framework.
Absolutely. The answer is better integration boundaries but then you’re paying the abstraction cost which might be higher.
It’s particularly difficult when the system under test includes an application that isn’t designed to be set up ephemerally such as application-level managed services with only ClickOps configuration, proprietary systems where such a request is atypical and prevented by egregious licensing costs, or those that contain a physical component (e.g. a POS with physical peripherals).
These printers also have an expansion network card.
A decade ago I worked on a project to deploy a couple hundred of these to a restaurant chain as part of a POC for an online ordering program for pickup orders. The requirement for each franchisee was to acquire a static IP and configure one of these printers to bind that static address using a network card that replaced the serial connection. The online interface from the vendor was configured with that static address and sent text over TCP to print the incoming orders. The printer than just printed whatever it received.
The project was initially deployed without any whitelisting or authentication (at the vendors behest) so for a couple months these printers were printing a mixture of garbage and scan attempts from random devices connecting. It was quite humorous at the time but scares the hell out of me given the other things that were on that internal network. The project failed for other reasons, but it looks like that particular vendor is still around.
Another strain of this is forcing some COTS application to work via a million hacks and integrations (usually via consulting resources) when a fundamental architecture or application change is needed. Responsibility coupled with the resource and authority to execute is stressful in its own way but it at least allows one to more easily own their failures.
Did you like the outcome and did it feel sustainable?
I'm so conditioned to providing buffered estimates, especially for highly-dependent systems, I would really struggle to not accidentally buffer. I'm generally invisibly factoring in organizational dependencies (e.g. Bob will need to stand up service X, but Aditya's approval of that will be subject ridiculous process Q that always takes two weeks). It sounds like this would invert the dependency tree if broken down well enough.
Cynically, I struggle to imagine working in such a high-trust environment that wouldn't immediately be destroyed.
They’re a fairly common design pattern https://en.m.wikipedia.org/wiki/Circuit_breaker_design_patte.... However, they certainly aren’t implemented with the frequency they should be at service level boundaries resulting in these sorts of cascading failures.
I think they both have their place, but I think acknowledging it as a system design choice is so helpful even in basic business processes (how will I handle exceptions, how will the person remember to handle a rare exception).
I find myself thinking of this problem frequently. We have lots of modern words for it like observability but I think that removes one a bit from the actual problem.