Comment by zevv | Hacker News Reader

Comment by zevv | Hacker News Reader

I am an embedded software engineer, and I love everything about this FSM example. It shows that seemingly simple and binary things often have more complexity then meets the eye. I love using old fashioned finite state machines for implementing all kinds of behavior; if forces you to think about every single state and transition, and it naturally isolates the different cases - basically, it makes it easier to think and talk about the implementation.

Buttons get even more fun when you add a "long push" to it. I can not recall how often I have had discussions with customers about the intended behavior of physical buttons on devices; it takes some effort and patience to explain how requirements like "Perform action A when the button is pushed, or perform action B when the button is pushed for a 3 seconds" simply can not be implemented. "Oh, so you mean, perform action A when the button us released within 3 seconds?". "Well, no I want it do A when I push the button".

And then I draw a little picture on the white board showing the circles and arrows.

This isn't quite as impossible as you make it sound. You can certainly make it feel like you have this behaviour by triggering A on release if the button is held for < ~300ms, or whatever feels right as a short press.

Of course now you have to accept the button doing nothing if it's held for longer than 300ms but shorter than 3s, but making it slowly fill up with another colour or something is probably enough to communicate the long press behaviour.

You: "So you want action A to happen immediately when the button is pushed AND 3 seconds after that when the button is still held action B should happen?"

Customer: "No, I only want action B when it is held for 3 seconds"

You: "Todays technology can't do that"

Customer: "What. Wait. Why?"

You: "Because at the point when action A would be triggered we would have to know the future to tell whether the button will have been held for 3 seconds or not."

PM: "Let's not rush into any hasty answers!"

(Under no circumstances should you show them this: https://www.youtube.com/watch?v=BKorP55Aqvg)

He should be fired for not suggesting 7-dimentional plot.

This is entertaining, but also cringe; clients and product people aren't generally idiots. They just have requirements that they can't adequately express.

Requirements capture is part of every eng job I've had.

I hear you and I understand what you're saying, those are some good points. Can you express what you require out of a none cringe comedy skit that this lacks?

They aren't generally idiots but sometimes their mental model of the problem space is incomplete and they don't understand what they're asking for. This is fine if they don't want to specify details. However when they do it can result in impossible requests.

Agreed, but as a former freelancer: Sometimes your customer doesn't know what they want and instead of figuring it out together they sketched together an internet-research-fuled plan that they want you to follow to the point, even if the plan is inefficient, doesn't solve their problem etc.

I usually managed to convince those people to come up together with a new plan while making sure they still feel like their original work is somewhat in there — after all I was the expert they came to with their issue, would be a bit idiotic to not pay for my expertise..

Sometimes this does not work, then I usually just told them I won't take that project. And projects like these don't make any sense, the customer will complain about their own planning mistakes as if it was your fault, you get angry, they get angry, everybody loses.

The best customers are those who know the problem they want to solve very well, as well as having some idea how a potential solution could look, but who thank you if you have an even better solution.

Lie about immediate effect, wait 1.5sec on press A. If it was <1sec press, proceed. Otherwise, wait for another 1.5sec and then work on B modality.

It depends on the lie, but I think it probably fits human-centric timescale.

The alternative is to work on the partially ordered set of events {A, B, undo-A} and convert to {A, undo-A}, {B} and then transform to {no-op, B}

Hysteresis/Queue is your friend.

> "Oh, so you mean, perform action A when the button us released within 3 seconds?". "Well, no I want it do A when I push the button".

It seems like what's gone wrong here is not that the customer wants something impossible, but that they don't understand what you mean when you say "perform action A when the button is released".

If you show one of those people a device with the behavior you describe -- e.g. "toggle a light if the button is released within 0.5 seconds, but toggle the other light, instead, if it's pressed and held for 3 seconds" -- would they agree that it does what they say they want?

Almost everyone understands "pushing a button" to include the action of releasing the button.

Been reading a few books about automaton (after going back into parsing) and it's indeed nice. There's something universal in them.

Is there a (mathematical if possible) way, using FSMs, to demonstrate if a specific case or behavior can or can't be implemented.

Yes there is. You may want to look into Deterministic and Non-Deterministic Finite Automata. They are foundational to computability and Turing machines.

https://en.wikipedia.org/wiki/Deterministic_finite_automaton...

You are designing a "prefix code". It is a collection of strings of button presses such as {A, BA, BBAA, BBABA, BBB, ...}. Each string maps to an action.

Ideally no string is a prefix of another string. Even more ideally any infinite sequence of As and Bs can be decoded into a sequence of actions.

Reply on news.ycombinator.com