Hacker News Reader

Comment by saagarjha | Hacker News Reader

This was actually less complicated that I had expected it to be.

I think the example still works because, while it is not too complicated to understand, it is also non-trivial. It's also probably more complicated than the typical non-technical person would think.

It's also worth mentioning that this diagram doesn't capture dataflow or the relationships between the subsystems needed to make this work. The logic for notifications requires interaction with user preferences, channel membership, comment parsing, thread management, and more[0].

All told, you may still be looking at (low) thousands of lines of code, with maybe 1.5-2x times that amount for test code.

[0] I'm just guessing how the app is structured internally. I have no idea what it is actually like.

It's also like 3 years old. Would love to see what it looks like now.

It's like never true, it does not show that you can't get email notification faster than in 30 minutes.

Also now should include adding random old stuff to notification.

Things like notifications have pressure on them to be simple, because users want to be able to decide when they will receive notifications, which means it needs to be easy for them to understand when they will and will not receive them with particular settings. I'm sure there are examples of some non-user-controlled decisions that have much more complicated flow charts.

Yes, it was something I'd never thought of before, but definitely simpler than I guessed before I clicked the link. That said, each time you add a conditional, you need to be increasingly careful about where you put it, and what other impacts it has.

I would also imagine that there are a variety of other features which require similar flow charts.

Yes, this is what my co-workers refer to as an if-statement.

I mean, the chart is still useful to have, and it'd be a couple of methods probably had I written it. But it's not a huge state space, and most of the transitions are fairly reasonable.

I can imagine it was quite a lot of work to come to such a clean and relatively simple chart.

Coming up with this chart from a generic ticket like "impl notifications" is one of the hardest parts of being a developer.

Code is generally the easy part once you know exactly what you're doing.

> one of the hardest parts of being a developer.

Not least because it's really the product designer and product owner's job to make this kind of chart.

Which they never do to a satisfactory level (in my experience). So it still falls on the developer to do it properly, then PO just copies it for their presentations.

This is not about how it translates into code. I see a lot of value in this diagram when compared to the half-assed "requirements" most PMs put in their JIRA tickets.

That is my takeaway: PMs and non-developers - you must think through the entire workflow. When you don't, your engineers will and will either pepper you with questions that you are not prepared for or they will decide for you.

I'm exactly on the same page, this is uncanny!

As an engineer, I consider fleshing out incomplete workflows to be one of the largest parts of my job. I've found the technique of saying "hey, the specification doesn't mention what to do in this situation, based on X/Y/Z elsewhere in the specification / this other similar feature, I'm operating under the assumption that it should work like <description of your best guess>. Let me know if that's mistaken". Then I make sure I have a commit of the state of the code, and start building based on the stated assumption.

A large fraction of the time, the PM just goes "that is correct", and the spec / ticket / whatever gets updated. When the answer is not "that is correct", you do lose out on whatever work you've done since sending that message, but writing code you eventually throw away isn't the end of the world. Also "that is not correct" responses often highlight areas where either the developer misunderstood what the PM was envisioning or the PM has a misunderstanding of what the system can do or how their proposed feature interacts with something else.

For this to work, you need:

1. Some variety of asynchronous channel that the developer can push stuff into at whatever frequency they want, and that the PM periodically catches up on entirely.

2. The developer to have a working understanding of how existing systems work and the system as a whole, from the business level.

3. The flexibility to modify specifications between the initial conception and implementation.

If you have all of those things, the PM doesn't necessarily need to think through the entire workflow beforehand -- it's nice if they can do that, but you can still ship working features without that and sometimes that is the pragmatic way to do it.

If you've thought about the entire workflow, all edge cases and the spec is 100% complete then you've written code, it's just a matter of whether humans or machines will compile it.

I find myself creating a lot of these diagrams to share with PMs (along with sequence diagrams, system architecture diagrams, decision tables, etc.).

Systematically articulating all of these different conditions isn't necessarily the strong suit of a PM, but they're generally quite capable of understanding and providing input to such documents.

All programming is just if statements. That doesn't mean systems can't be complex.

Not true; if the conditional branch goes backward then it's a (possibly do-) while statement. Also subroutine calls.

Counternitpick: Those subrouting calls and while statements are compiled to conditional jmps. If you squint your eyes it's just a fancy 'if'.

"It's no use, @a1369209993 - it's IF statements all the way down!"

Apologies to William James' apocryphal quote.

If you're creative you can get away without conditional branches: http://www.jucs.org/jucs_2_11/conditional_branching_is_not/R...

Reply on news.ycombinator.com