Ask HN: Do you make a work breakdown structure before programming?

[julienreszka]

Do you make a work breakdown structure before programming?

Something like this

  - [ ] Project A
    - [ ] Feature AA
      - [ ] Component AAA
        - [ ] Functionality AAAA Allows users to do something by doing something
        - [ ] Functionality AAAB Allows users to do something by doing something
      - [ ] Component AAB
    - [ ] Feature AB
      - [ ] Component ABA
      - [ ] Component ABB
      - [ ] Component ABC

This is just dummy data to give an idea

Do you use markdown or do you use dedicated software?

[swah]

JIRA because one has to at $JOB.

Personally I have the hardest time with breaking down in the sense of having a good estimate. Breaking down in terms of screens/pages works super well, backend vs frontend tasks. But more than that I have a hard time. The details I mean.

Ideally I would prototype, throw away and then do it properly. I'm very optimistic and create only 3 or 4 tasks, in the end its always 12 because of details that I missed.

[eternityforest]

I make a simple flat todo list if I'm not following any particular formal methodology.

Productivity porn is fun but not quite fun enough that I want to deal with more dedicated tools.

Generally I'll use Google keep, but I might also use a markdown file right in the repo, or sometimes, I will actually use my tablet and stylus in a Keep note, in an attempt to replicate some of the mental benefits of paper without going to quite that much effort and using the real thing.

Semi-real example from personal a project idea:

* Show nodes on map layers

* Click node to get inspector window

* API to create map layers

* API must have permission system

* Inspector window allows sending chat messages to node

* Telemetry data

* Persistence and history is handled by backend

* API let's host query history

"It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it."

https://spacecraft.ssl.umd.edu/akins_laws.html

[muzani]

Yeah, exactly that. Workflowy is perfect for this. Use my referral code to get 250 free items: https://workflowy.com/invite/fc6cd0b.lnx

We also do syncs and performance reviews where we reflect on work done in the past X weeks/months. So this kind of format is very useful because you can also see effort and frustration around cettain tasks.

I break it down further to sprints/weeks, days, which items are to be resolved on what days. Normally I try to plan for everything to be done by Wednesday, then it tends to expand into Friday lol.

Sometimes a list of tests that should pass as well to consider this item fixed.

[vegetablepotpie]

WBS works great if you are building structures.

WBS fails hard if you’re trying to achieve an outcome.

For most engineering activities, I’ve found developing a knowledge point plan is a better mapping to the work being done.

[gsuuon]

I write a hierarchical structured task list (very similar to op) with a neovim plugin I wrote (https://github.com/gsuuon/note.nvim). Sometimes I'll write these items as commit messages, make the changes and check them off as I commit. I mark the current task so that if I get interrupted I can recontextualize fairly quickly.

[AnimalMuppet]

You should know what you're trying to do before you start programming, yes. (Unless you're exploring the options.) That could just be a task list, if it's a simple, well-known (to you) problem. If not, then you want more. You want a design, maybe even an architecture.

Don't code before thinking and planning. The bigger the program, the more time and detail in the thinking and planning before you start coding.

[pillefitz]

What is your actual question?

[bjourne]

Nope. I make mind maps. My development process is much too chaotic to be captured by a checkbox tree.