5 ms·

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

saagarjha 6y ago
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.
- Drdrdrq 6y ago
  I can imagine it was quite a lot of work to come to such a clean and relatively simple chart.
  - hombre_fatal 6y ago
    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.
    - zimpenfish 6y ago
      > 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.
      - Drdrdrq 6y ago
        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.
dudul 6y ago
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.
- sethammons 6y ago
  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.
  - dudul 6y ago
    I'm exactly on the same page, this is uncanny!
  - JoshuaDavid 6y ago
    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.
  - flukus 6y ago
    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.
paxys 6y ago
All programming is just if statements. That doesn't mean systems can't be complex.
- a1369209993 6y ago
  Not true; if the conditional branch goes backward then it's a (possibly do-) while statement. Also subroutine calls.
  - seisvelas 6y ago
    Counternitpick: Those subrouting calls and while statements are compiled to conditional jmps. If you squint your eyes it's just a fancy 'if'.
    - zimpenfish 6y ago
      "It's no use, @a1369209993 - it's IF statements all the way down!" Apologies to William James' apocryphal quote.
- adrianN 6y ago
  If you're creative you can get away without conditional branches: http://www.jucs.org/jucs_2_11/conditional_branching_is_not/Rojas_R.html http://www.jucs.org/jucs_2_11/conditional_branching_is_not/R...

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.

Drdrdrq 6y ago
I can imagine it was quite a lot of work to come to such a clean and relatively simple chart.
- hombre_fatal 6y ago
  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.
  - zimpenfish 6y ago
    > 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.
    - Drdrdrq 6y ago
      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.

dudul 6y ago

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.

sethammons 6y ago
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.
- dudul 6y ago
  I'm exactly on the same page, this is uncanny!
- JoshuaDavid 6y ago
  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.
- flukus 6y ago
  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.

paxys 6y ago

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

a1369209993 6y ago
Not true; if the conditional branch goes backward then it's a (possibly do-) while statement. Also subroutine calls.
- seisvelas 6y ago
  Counternitpick: Those subrouting calls and while statements are compiled to conditional jmps. If you squint your eyes it's just a fancy 'if'.
  - zimpenfish 6y ago
    "It's no use, @a1369209993 - it's IF statements all the way down!" Apologies to William James' apocryphal quote.
adrianN 6y ago
If you're creative you can get away without conditional branches: http://www.jucs.org/jucs_2_11/conditional_branching_is_not/Rojas_R.html http://www.jucs.org/jucs_2_11/conditional_branching_is_not/R...