Hacker News new | past | comments | ask | show | jobs | submit login

At my old programming job, people would come up to me all the time asking if I could write programs to automate business processes. One day someone called a meeting to discuss a new software system that would help prevent incorrect box labels from being stuck on finished goods. She explained that the problem was that label designs change frequently and sometimes older, expired labels get used instead of the new labels. Mistakes like that are expensive to rectify and though we have many failsafes in place (lot tracking with expiration, multiple QC inspection stages etc.), the only surefire way to prevent errors would be to compare the customer-approved "Master" label for each production job with one of the printed sticky labels before a job starts.

Her group's suggestion was that I build a simple system that maintains an electronic catalog of all the Master labels for all the production jobs, and before each job is run, a production employee would scan in a sample of the printed box labels. Then my system could do its magic and let the employee know if the Master label matches the printed label. If so, they can continue with production.

As I listened to their request, cogs were already starting to turn in my brain: CRUD system to manage Master labels, versioning for each label, preassigning Masters to specific jobs based on customer approval, scanning labels from the manufacturing area, graphical diff. with auto-orientation matching, and documenting/validating this entire system. Hmm. Let's see if there is an easier way.

Me: Why can't the production employees compare the labels by just looking at them?

Her: Because sometimes it's just a few sentences or design elements that change. It's easy to miss and has happened a few times.

Me: Who provides us the Master labels?

Her: The customer. And we make it a part of the production paperwork well-in-advance and get it approved by the customer so there is never a mixup on the Master itself.

Me: Sounds logical. How are the sticky labels printed?

Her: Depends. We may print them ourselves if it's just a few hundred or get them printed by label vendors for large quantities. We may reuse them in multiple jobs and so may warehouse them for future use.

Me: So before every production job, someone goes to the warehouse, looks for a stack of printed labels in the racks by Item# / Bin#, and brings them back to the production room?

Her: Yes. And that's when errors happen. They might bring back the wrong version of the label and not realize it. Or people in the previous shift might have returned unused labels into the wrong bin etc.

Me: OK. So just to recap, our production team can get the correct Master label every time because it is part of the paperwork already approved by the customer, but errors happen because there could be 10 very similar versions of the same label in the warehouse and the employee might pick the wrong one.

Her: Correct.

Me: One way to prevent such errors would be to add Version# to every lot of every label item we have in the warehouse and have the barcode scanners block movement of incorrect versions, however that requires a tremendous effort of data-entry, programming, and training.

Her: Absolutely. That's why we just want to compare the Master with the printed samples automatically.

Me: What size are these Master labels in?

Her: Centered on regular 8.5x11.

Me: And the printed labels are also centered on 8.5x11 and same size as the Master labels?

Her: Yes.

Me: What if the prodution employee photocopies the Master label to a transparency sheet and overlays it on the printed labels? I know we have copiers in the area.


everyone looks at each other and nods in agreement

Her: That'll work. Thanks everyone. Let's get some lunch.

I'm quite impressed that your suggestion was accepted, in the company where I work this would never happen.

An example: I was asked to build a system to keep track of daily tasks of one of our teams, and to make sure all scheduled tasks were assigned to someone. As I was listening to them, I suddenly realized that the magnetic white-board on the meeting room wall was all they needed. I drew a table with team-members names and weekdays and used the magnets as tasks.

After some silence the team supervisor said it would work, but would not be used because: a) it looks 'unprofessional'; b) it's 'insecure' because someone could mess up the magnets by accident

After some emails between my manager and them my colleague was ordered to build the system, he ended up spending about 3 weeks on it :)

It was a relatively small company and people really tried their best to solve problems in efficient ways. I think they missed the obvious solution purely by chance.

It's kind of sad that the skill demonstrated here is often the most important skill of a programmer: solving problems with the simplest approach possible. unfortunately, many companies fail to acknowledge that the real superstars are these people, and not the people who'd say "ok, but i'll need a 3 person team and 2 months".

Well done. It's important to get the context and understand what your customer's looking for.

All too often we "listen" to a customer and implement a suggestion, not realizing it's a horrible solution to a problem they haven't fully realized.

The world needs better listeners.

Awesome. Did she pay for your lunch?

That was a good story. I have some 'interesting' WMS and inventory control stories.

What WMS were you using?

MS Dynamics + lots of customization.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact