3 ms·
Ask HN: Do you make a work breakdown structure before programming?
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?
- eternityforest 3y agoI 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 https://spacecraft.ssl.umd.edu/akins_laws.html
- swah 3y agoJIRA 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.
- pillefitz 3y agoWhat is your actual question?
- AnimalMuppet 3y agoYou 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.
- gsuuon 3y agoI write a hierarchical structured task list (very similar to op) with a neovim plugin I wrote (https://github.com/gsuuon/note.nvim 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.
- muzani 3y agoYeah, exactly that. Workflowy is perfect for this. Use my referral code to get 250 free items: https://workflowy.com/invite/fc6cd0b.lnx 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.
- deleted 3y ago[deleted]
- vegetablepotpie 3y agoWBS 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.
- bjourne 3y agoNope. I make mind maps. My development process is much too chaotic to be captured by a checkbox tree.