11 ms·

Breaking down tasks

317 points by Timothee 3y ago

hartator 3y ago
I don’t know. I think that’s the main truth about software engineering. Maybe an open source version of that Streak app exists and OP is re-inventing the wheel. I think the brain doesn’t like task list. It may be pleasant to do, but most of entrepreneurship or coding is exploring. And a task list blocks you from exploring.
- ideamotor 3y ago
  Agree, the entire point of a task list is to block yourself from doing other things. That makes sense until it doesn't. "The map is not the territory".
- jacobian 3y ago
  I'm curious: if you hired a contractor to, I dunno, paint your walls, would you accept "I don't know" as a time frame or price quote? If not, what's different about software development that makes "I don't know" a reasonable answer in our profession?
  - Jtsummers 3y ago
    Software development isn't (universally) a painting type task. In painting a room, the painter can estimate (by measuring) the amount of paint needed, they know from experience the time to acquire a particular color (if it needs to be mixed or can be bought readymade) in a particular volume, they know how long it takes to paint (they've done it many times before), how long to dry, and how many coats are needed for the type of surface. Now, ask them to paint a mural instead. The estimates will change, they'll probably give you a broader range instead of being able to estimate almost down to the minute (and being off by no more than an hour or two) like someone just painting walls (with a known environment, surface type, and paint material). Does the mural need to be designed? Are the desired qualities of the mural well-specified or will there be a series of back and forths? Maybe a set of prototypes (sketches) so that you can refine your requirements. At that point, the estimate for the total task (design and paint a mural, or design and develop a software application) becomes far less clear. There are certainly programming tasks which are closer to the paint-a-wall task which are much easier to estimate reliably, but they're far from the only thing people in this field work on.
    - kvmet 3y ago
      This kind of thing destroys freelance devs who don't have context. Customer: "Hi we need this small change." Dev: "No problem! Here's a quote for 4 hours" Ignoring that 4 hours is probably less than the effort to consult, estimate, generate and process contracts, bill, do taxes... Then the customer comes back and asks for a revision which will at least require a Change-Order or a separate PO. To some extent the overhead should be covered under labor burden but the reality is that in a sole proprietorship YOU are also the person doing the labor that is within the definition of "labor burden". It adds up extremely fast. A million dollars would be a windfall if it landed in my checking account. On a development project with hardware and more than one dev it might as well be dust in the wind.
  - beryilma 3y ago
    Contractor horror stories are actually very common. They may not actually say to you "I don't know", but big delays in contractor jobs happen all the time. I would argue that software engineers are at least trying to be more honest about the unknowns of the work unlike some sleazy contractors.
  - xboxnolifes 3y ago
    > what's different about software development that makes "I don't know" a reasonable answer in our profession? The seemingly infinite amount of variations in software tasks and the ambiguity of the requirements? If my job involved only putting up or modifying API endpoints that involved querying a single SQL database, I'd get quite good at that and be able to tell you with very good accuracy how long an endpoint would take to put up. Just as if I painted many walls before, I could reasonably tell you how long painting a wall would take based on the surface area, height, and amount of non-wall obstructions. Also, contractors tend to be their own salesmen, so just because they speak confidently, doesn't mean they are. It's not like contractors are universally famous for being on-time and underbudget.
    - Cyphase 3y ago
      If your job involved _only_ putting up or modifying API endpoints that involved querying a single SQL database, you could automate at least a good chunk of that. Maybe all of it. How long would it take to build a system to automate API endpoints that query a single SQL database? It depends.
  - sanderjd 3y ago
    My answer to this is that software engineering is a lot more like creating a blueprint than creating an artifact based on that blueprint. Or put another way, it's usually more of a design process than a manufacturing process. (I've switched analogies on you, but "painting walls" in your analogy is akin to "manufacturing artifacts" in mine.) The "manufacturing the artifact" step in software is done automatically by the computer, when given the "blueprint" (code). I guess to try to go back to your painting walls analogy. In my view, creating software is more like if someone asked you to create a wall-painting machine that will work for any room that fits a certain specification. They could contract you to paint just one room in this way, but that would certainly be harder than just painting the room! But more likely, they have a million rooms they want you to paint. Either way, the hard part is creating the room-painting machine. And it would indeed be quite difficult to give an accurate estimate of how long it will take to do that. But once that exists, you can easily estimate how long it will take to paint any individual room. And real engineers, indeed, have this same issue with the design phase of projects, for the same reasons. Just like us, they try to break apart and estimate how long it will take to do that part, but just like us, my impression is that it is known to be fraught to accurately estimate that part of a project. But also just like us, this is a continuum based on how novel the thing they are engineering is to them. On the one end of the spectrum, there is the equivalent of off-the-shelf software, like using a blueprint for a standard single-family home that's been built a million times already. And on the other end of the spectrum are things like designing the motor for the first model of a new electric vehicle manufacturer, where it's all brand new. But then there's a whole spectrum between those two, where it is fairly easy to break down and estimate the design process for things you've done a bunch of times, and nearly impossible for things you've never done. This is a very long-winded way of saying that the difference comes down to how novel the project you're working on is! This is why freelance / contractor shops do best when they find a particular niche of a kind of thing to build, and then find clients who want them to build essentially the same thing over and over again. It really is possible to get very good at estimating this kind of nearly-cookie-cutter work. (I did this a bit for awhile back in the day, with multi-page Rails CRUD apps, and it was indeed easy to break things up and estimate.) But this is also why it can be frustrating to work with freelance / contract shops, because it behooves them to figure out how to fit your project into their cookie cutter, and that can end up being a worse outcome than building something bespoke, iteratively, without a detailed plan and estimate.
tonymet 3y ago
The best way to estimate is to start work and benchmark your progress against your estimates
- swah 3y ago
  Another post has this part: https://jacobian.org/2021/may/25/my-estimation-technique/#5-track-your-accuracy-so-you-can-improve-over-time https://jacobian.org/2021/may/25/my-estimation-technique/#5-...
roenxi 3y ago
This gets a lot of teachers - the task is so ingrained in them that the only part they consciously understand is the trivial bit that everyone already gets. Breaking down a task and estimation are almost equivalent - once the breakdown is done, assigning estimates to the chinks of work takes a few minutes as anyone with a few years experience has some standard estimates for small tasks. In my experience I break down a task by biting off chunks that I can estimate, then ask for opinions on anything I can't. Although I don't even believe the real path to mastery is the task breakdown. Anyone can come up with a bad breakdown. The real point of mastery, which he didn't talk about here, is identifying when the evidence suggests a task breakdown is incorrect enough to cause problems and communicating that / doing a re-estimate [0]. And being comfortable that it will happen so not getting stressed up front putting out a schedule that is likely to change. Managers generally want an accurate roadmap up front. This is them asking for the impossible. IMO Good management is about flexibility and understanding that the expected nature of the work changes as time passes and developers learn. He has a little example at the end. Ponder that if someone had come to him with an accurate estimate ("you can do this in a few evenings as a plane trip") he'd have rejected that as too risky. That illustrates that estimating isn't even about accuracy, there are many unspoken factors here around risk management, expectation management, task familiarity, etc, etc. [0] https://jacobian.org/2021/jun/8/incorrect-estimates/ https://jacobian.org/2021/jun/8/incorrect-estimates/ - he has a post on the topic
- WaxProlix 3y ago
  Really great, honest and refreshing link - my thanks for posting it.
teeray 3y ago
Breaking down work works great until the breakdown is unknowable. Things like research, that require creative experiments to POC things that are not known apriori. That’s when task breakdown breaks down.
- winwang 3y ago
  ...and then you break out the actuarial models :) And at some point, you just gotta do it.
- al_borland 3y ago
  Also when management sees what should be a POC or research as a deliverable they start promising to higher ups and other teams. I’ve developed the habit of doing most of my POC work behind closed doors and telling no one. If it works great, I can release it. If it doesn’t, I can kill it and move on without having to eat crow, or get told I need to figure out a way to make it work after I’ve seen it’s not wise to continue.
  - beebmam 3y ago
    I'm jealous that you have such flexibility at work that you can do POCs behind closed doors!
- throwaway346434 3y ago
  Nah, that's easy to solve. "spend 3 hours on investigating X, 3 on Y, 3 on Z"; and then have a planning session about what to do next. You have 4 outcomes - the first one solves it, the second, the third or none. If it is solvable with mild effort, you have a 50% chance of solving it by attempt 2/6 hours.
  - n4r9 3y ago
    It sounds like a pretty small problem if you can build a PoC in 3 hours. Sometimes it takes 3 days to get to a point where you have a rough idea of what code changes might be needed.
itsgrimetime 3y ago
Maybe I’m just lazy/undisciplined/a cowboy but having to break things down into “pointable” tasks feels like busy work just so management can “see” progress. I mean, thinking through a problem you’re trying to solve before starting makes sense, and having rough milestones is important - but a majority of the time there’s so many unknown unknowns that fully breaking it down is totally useless, if not impossible. If I spent the same amount of time it took me to break a project down just working on figuring out a solution or building it, it’d get done way sooner. At least, that’s how it feels.
- jsmeaton 3y ago
  > feels like busy work just so management can “see” progress Lot's of people feel like this. I usually come at it a different way - we're trying to estimate effort to see if we want to attempt building it in the first place. Assisting with the cost-benefit question if you will. That's the first reason. It can also be extremely beneficial to the team, particularly when working with less experienced folks. You can farm out a lot of the work and parallelise the task. I suspect Jacob didn't do much of this breakdown when implementing his streak app, which is why he recurses in an illustrative way.
- sateesh 3y ago
  Ignoring management part, one place where I have found breaking down to be helpful is when I have to work on some thing which I am not terribly motivated todo (say it is boring, lethargy, or it looks too daunting). In such cases I have found it useful to break down to smaller tasks and keep completing each of them which in turn generates a momentum to continue, as I have been able to make some progress from a situation where I was essentially in a deadlock (or was lethargic to work on).
- throw1234651234 3y ago
  I mostly disagree with you if you work in a "standard" company - it's usually "make a form" or "move data / do some other CRUD". These tasks don't generally have that many unknowns. It's absolutely valuable for managers to be able to estimate velocity as well, though the problem is that they really do stop understanding "we are not sure" once you spoil them. I am a consultant too, so it's critical for me to say "we are delivering this, in this much time", even though we are "agile".
tareqak 3y ago
> Delivers change because, in a work context, a task only “matters” if something is different because of the work. I think maintenance tasks may require more effort / more expansive qualification when it comes to the meaning(s) of "something is different". I think the topic of "breaking down tasks" could very well be its own book genre or even podcast genre. My experience with self-help and organization titles has been that the activity of breaking down tasks is a sort of known primitive human operation that many authors assume their readers to have. However, my own personal experience and the accounts of others I have heard while participating in group sessions is that breaking down tasks can be very difficult and provoke emotions of avoidance and despair. The most broadly relevant advice that I have come across when it comes to breaking down tasks is to keep breaking things down until I am 90% certain that I can successfully complete the task. The certainty here would vary on how much self-confidence an individual has and their risk tolerance, so some people may break down tasks to 70% certainty of success.
- XorNot 3y ago
  The problem I have with task breakdowns is you get way too much engineer overconfidence - i.e. there is literally no task which is less then an entire day's effort, in practice. There's about 6 usable hours in a day - I've watched people confidently bid they'll get something done in "half a day" but when you point out that's about 3 hours, suddenly they're way less sure about that number - or offended. Then 3 days later they're still working on it.
  - devsda 3y ago
    Sometimes it is not overconfidence but a side-effect of management interference & second-guessing the estimates. In this case engineers give an estimate of what they think management wants to hear and not the actual time it takes. It happens if they are frequently asked to reduce their estimated time to within management expectations. To deal with this, you need to bargain with them in the opposite direction to make sure the estimates are realistic.
    - bruce511 3y ago
m3kw9 3y ago
Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown
- petersellers 3y ago
  Isn't it more likely that you can catch yourself during the planning phase if the amount of work being estimated exceeds your budget? That seems much cheaper and easier to pivot from than if you were to make that realization halfway through your implementation.
  - m3kw9 3y ago
    I think it’s par for the course because you can only plan so far before you run into miscalculations once you start doing it. You break down tasks for stuff very close range
- lelanthran 3y ago
  > Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown Similarly, if you don't plan enough, and get far enough into a small project, you don't change your approach because of the sunk cost fallacy.
  - m3kw9 3y ago
    Right, you are susceptible to it either way. In that case breaking down a task can potentially get you way further
hnaccountme 3y ago
Software development cannot be managed like this. This sort of task break downs come from classic management training. The problem most people are unaware of is software development is more a creative activity than anything else. Yes there are serious technical aspects to it but since the problem is virtual and not bound by any real world limitations, like how civil engineering would be, there isn't one optimal solution. Trying to define the solution before the problem has been properly examined would only limit the final output. Most of the exploration only happens when people actually start coding. Not having a well defined final output and time is not very relevant for software, mostly because there is no per unit cost. Most managers do not realize this is they are not from a software engineering background. A versatile product can be sold to many different customers without additional development costs. But since most companies are managed as factories, all the processors will ultimately create a very limited product targeted at a specific customer. What the big tech companies have avoided is this .
- rolisz 3y ago
  You'd be surprised how much creative tasks like 3D modeling and creating artwork can be broken down into tasks that are very well defined and can be estimated quite correctly.
  - makeitdouble 3y ago
    I think it would fall down the same lines if you required a coherent world and high quality for each of the models you create. That would mean redo models that don't fit the whole piece, endless tweak some models that are really difficult to get right, sometimes do swiping changing across all the parts because as a team you realize something is off etc. The balance will be between delivering something within a time frame, and delivering the quality that was requested/expected.
  - heisenbit 3y ago
    The difference is that you break down software into smaller and smaller bits and then find a small bit that needs data from a far away small bit. I suspect this happens less with mechanical systems.
082349872349872 3y ago
compare https://shitpost.plover.com/o/omega-omega.html https://shitpost.plover.com/o/omega-omega.html
Scarblac 3y ago
I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make something is put in the first part. And then, the rest is still most of the work, but it's the really boring part. It's much more fun (and therefore faster, and resulting in better work) to spread the creativity and the boredom out more equally. The two are probably related, and it's not inconceivable that I have ADHD.
- suslik 3y ago
  I am somewhat like that myself. I do formulate a plan and break down tasks in advance, but I give myself an absolute right to change and modify it at will whenever new ideas come to light or just because I'm feeling like it.
- Rygian 3y ago
  > the plan is never followed The plan not being perfect and prescient is part of the plan. Next time you plan for same or similar activity, your future plan will be better. The Project Managers even have a mantra: "fail to plan is plan to fail."
  - Scarblac 3y ago
    And Eisenhower's "plans are useless, planning is essential", of course. I know. But for me it's very easy to overdo it. Give me interesting chunks of about a week or two, with a tight deadline, and I'll do my best work. Remember, Linus wrote Git in two weeks. And there was no project manager in sight.
    - baliex 3y ago
      On the Linus point, I'd bet there were countless months where he was bringing ideas together in his head and planning how he'd do it before actually finding the time to sit down and write it.
TomatoDash 3y ago
Good read! I wish we had a shorter name for "breaking down tasks". Perhaps taskspec, short for "task specifying". Or taskdev?
- swah 3y ago
  "refinement" in JIRA world I think
segfaltnh 3y ago
A lot of the "never taskers" in this comment section seemed to have never worked with the juniors I have. These are good, new software folks who genuinely don't know how to stand up basic functionality because the space is new to them. In my experience they want tasks they can learn from and excel at, leading to growth. I think the thing that you absolutely must keep in mind is process overhead is a continuum you tune to your team. No one in the NBA is going into a huddle and getting instruction on how to throw a ball mid game, but the kids in third grade are. Both styles of planning and coaching are appropriate to the team at hand.
globular-toast 3y ago
What's missing here is who this breakdown should be shared with. There are three levels of breakdown and the details of lower levels should never be revealed to higher levels: 1. The "business" level. There are no "tasks". There are only needs and desires. Things like "a user can log in and press a button". These should not be broken down further than the smallest unit of deliverable value. In this example, there's no point estimating "user can log in" because it delivers no value on its own. A good rule of thumb is these should be described using descriptive language, not imperative, so not e.g. "implement log in procedure". 2. The "team" level. It's OK here to break down those things into "user can log in" and "logged in user can press button". That's because you know they can be implemented independently. But there's still no point delivering them independently. Don't tell the upper level about this breakdown. They are always really eager to know, but they don't need to know. Use this to calculate your estimate for level 1, but said estimate should be a single aggregate. Implementing these in parallel with multiple devs adds no extra overhead because they are completely independent. 3. The "developer" level. This is where you finally have "tasks" and imperative language. Things like "add button to form", "implement 2FA" etc. These tasks are naturally heavily dependent on each other and it's highly likely they'll be done in a completely different order to whatever you write them down in. If you decide to distribute these tasks among developers then you increase the coordination overhead between devs. Think of it like a multi-threaded application. It's always more efficient for a single developer to do everything if possible (less overhead), but it might nevertheless be necessary to split it up due to time constraints, differing skillsets etc. It's just like we'd like to have one single 80GHz general purpose CPU, but in reality we have to make do with 16 5GHz cores split between performance and efficiency cores etc. Given that the tasks are highly likely to change and evolve, there is not much point putting in loads of effort to break things down. Do it only when it's necessary, or when it helps you. It's necessary when you need to split up the work between developers. It's helpful when you think of more tasks during your work and you don't want to break your stack. Every developer should have a way to quickly take notes in a way that doesn't break flow, things like "ensure API accepts float input". This is stuff you'd never think of before you get your teeth into it.
- firewolf34 3y ago
  Can you elaborate on why we wouldn't share the carefully estimated project plan breakdown with Level 1? I'm not disagreeing, just curious - one would think that with doing all the work to achieve a solid project plan breakdown and Gantt charts and such, it would behoove you to express this to management who is salivating over tangible examples of progress... I understand we don't want to show technical to non-technical, but part of the good project plan is the fact that we can show a roll-up of the tasks, so the abstraction is visible. It's hierarchical.
ChrisMarshallNY 3y ago
This reminds me a bit of the old "Write a story about the task. The nouns are objects, and the verbs are methods." method of OOP. I never warmed to that. However, this is not that, and I think it's an important skill. I started my professional life as an RF technician, and we learned how to do this, almost immediately. We used things like signal generators and oscopes.
deleted 3y ago
[deleted]
alkonaut 3y ago
The biggest problem I have with splitting tasks is reluctance to do duplicate or unnecessary work. Breaking down tasks into smaller tasks means you must do duplicate work. The trick is to minimize it. If you try to make no unnecessary work, you'll end up having to do everything at once. Example: you want to refactor a program with two modules A and B where B depends on A. The least wasteful way of doing it is to refactor both modules together. But it's also the riskiest and hardest to estimate. The broken down way is to refactor A and adapt B so that it works with the refactored A. After that you would refactor A, which would then risk making the adaptation effort very short lived. If you want to do zero throwaway effort, you often can't break down the task. I have 20 years of experience and I still often find myself reluctant to do throwaway/temporary job in order to divide work. Instead I find myself doing multi-week efforts with zero yaks left unshaved.
throw1234651234 3y ago
Does anyone have a better article on this? This is ok, but it seems like there are better - I would love to share with my team. These are things I always share with them: On code reviews: https://mtlynch.io/code-review-love/ https://mtlynch.io/code-review-love/ On simplicity: https://grugbrain.dev/ https://grugbrain.dev/ On SOLID (even though we use Python now): https://www.baeldung.com/solid-principles https://www.baeldung.com/solid-principles I would love to have a "standard" article for planning.
nate 3y ago
Being a career long engineer, I'm not unaccustomed to breaking down huge projects into smaller things that can be parallelized, plotted in time, etc. We have to do it and get better at it. But honestly, I think what holds most of us back is a better ability to just don't do that. Take that thing you want to make, and instead of planning out all the pieces, just make the tiniest possible thing that could possibly be of value. Using this example, just start with "Today" and the 4 buttons. Make a thing that shows your 4 buttons of exercise you will click on each day. You can probably make that today. No streaks or freezes or calendar view. Those are all great ideas, and you'll get to them. But you need momentum. And you'll probably decide you don't even like that calendar view in a few days. I think more projects need a kick in the pants of just do something small. Get it done today. See what the next task is from that point because it's probably not what you thought it ought to be during the planning phase. This also isn't exactly easy either. It requires some thought and discipline and find the smallest thing and commit to shipping it without distraction. But it's also something good to practice at.
- sanderjd 3y ago
  I have come to think of this as "The Anna Principle" in organizing my own work: > when faced with uncertainty, one must simply focus on doing "The Next Right Thing." [0] This is not to trivialize it! Figuring out the next right thing to do is hard, but also the most valuable part of planning, in my view. 0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
  - rhapsodic 3y ago
    "Do the next right thing" was a phrased used by Alcoholics Anonymous long before that 2019 movie came out, so I don't think calling it "The Anna Principle" is appropriate.
    - sanderjd 3y ago
      I didn't know this! That just makes me appreciate this more, and thank you for making me aware of it. But thinking of it as "The Anna Principle", named after a character from a children's movie, remains way more fun. It was already a tongue-in-cheek-ism to ascribe what I really do believe is a strong foundational idea (not just in project planning, but in life) to a character in a children's movie. By the way, I tracked this back to at least one earlier use of a similar construction (which maybe is implied to be the basis of its use in AA) by Carl Jung: > But if you do with conviction the next and most necessary thing, you are always doing something meaningful and intended by fate. Excerpted from: https://www.themarginalian.org/2021/12/07/carl-jung-next-right-thing/ https://www.themarginalian.org/2021/12/07/carl-jung-next-rig... But I suspect this is an even older, indeed timeless, idea. But ascribing it to a modern well-known movie character makes it more fun and memorable :)
swah 3y ago
Meta: any other blogs like this one? I really enjoy the writing, the topics..
alexakten 3y ago
I created tasktree.co for myself to help with this! It’s so easy to get overwhelmed when faced with a big task, and actually forcing yourself to just break it down helps a lot.
deleted 3y ago
[deleted]

317 points by Timothee 3y ago

I don’t know. I think that’s the main truth about software engineering. Maybe an open source version of that Streak app exists and OP is re-inventing the wheel. I think the brain doesn’t like task list. It may be pleasant to do, but most of entrepreneurship or coding is exploring. And a task list blocks you from exploring.

ideamotor 3y ago
Agree, the entire point of a task list is to block yourself from doing other things. That makes sense until it doesn't. "The map is not the territory".
jacobian 3y ago
I'm curious: if you hired a contractor to, I dunno, paint your walls, would you accept "I don't know" as a time frame or price quote? If not, what's different about software development that makes "I don't know" a reasonable answer in our profession?
- Jtsummers 3y ago
  Software development isn't (universally) a painting type task. In painting a room, the painter can estimate (by measuring) the amount of paint needed, they know from experience the time to acquire a particular color (if it needs to be mixed or can be bought readymade) in a particular volume, they know how long it takes to paint (they've done it many times before), how long to dry, and how many coats are needed for the type of surface. Now, ask them to paint a mural instead. The estimates will change, they'll probably give you a broader range instead of being able to estimate almost down to the minute (and being off by no more than an hour or two) like someone just painting walls (with a known environment, surface type, and paint material). Does the mural need to be designed? Are the desired qualities of the mural well-specified or will there be a series of back and forths? Maybe a set of prototypes (sketches) so that you can refine your requirements. At that point, the estimate for the total task (design and paint a mural, or design and develop a software application) becomes far less clear. There are certainly programming tasks which are closer to the paint-a-wall task which are much easier to estimate reliably, but they're far from the only thing people in this field work on.
  - kvmet 3y ago
    This kind of thing destroys freelance devs who don't have context. Customer: "Hi we need this small change." Dev: "No problem! Here's a quote for 4 hours" Ignoring that 4 hours is probably less than the effort to consult, estimate, generate and process contracts, bill, do taxes... Then the customer comes back and asks for a revision which will at least require a Change-Order or a separate PO. To some extent the overhead should be covered under labor burden but the reality is that in a sole proprietorship YOU are also the person doing the labor that is within the definition of "labor burden". It adds up extremely fast. A million dollars would be a windfall if it landed in my checking account. On a development project with hardware and more than one dev it might as well be dust in the wind.
- beryilma 3y ago
  Contractor horror stories are actually very common. They may not actually say to you "I don't know", but big delays in contractor jobs happen all the time. I would argue that software engineers are at least trying to be more honest about the unknowns of the work unlike some sleazy contractors.
- xboxnolifes 3y ago
  > what's different about software development that makes "I don't know" a reasonable answer in our profession? The seemingly infinite amount of variations in software tasks and the ambiguity of the requirements? If my job involved only putting up or modifying API endpoints that involved querying a single SQL database, I'd get quite good at that and be able to tell you with very good accuracy how long an endpoint would take to put up. Just as if I painted many walls before, I could reasonably tell you how long painting a wall would take based on the surface area, height, and amount of non-wall obstructions. Also, contractors tend to be their own salesmen, so just because they speak confidently, doesn't mean they are. It's not like contractors are universally famous for being on-time and underbudget.
  - Cyphase 3y ago
    If your job involved _only_ putting up or modifying API endpoints that involved querying a single SQL database, you could automate at least a good chunk of that. Maybe all of it. How long would it take to build a system to automate API endpoints that query a single SQL database? It depends.
- sanderjd 3y ago
  My answer to this is that software engineering is a lot more like creating a blueprint than creating an artifact based on that blueprint. Or put another way, it's usually more of a design process than a manufacturing process. (I've switched analogies on you, but "painting walls" in your analogy is akin to "manufacturing artifacts" in mine.) The "manufacturing the artifact" step in software is done automatically by the computer, when given the "blueprint" (code). I guess to try to go back to your painting walls analogy. In my view, creating software is more like if someone asked you to create a wall-painting machine that will work for any room that fits a certain specification. They could contract you to paint just one room in this way, but that would certainly be harder than just painting the room! But more likely, they have a million rooms they want you to paint. Either way, the hard part is creating the room-painting machine. And it would indeed be quite difficult to give an accurate estimate of how long it will take to do that. But once that exists, you can easily estimate how long it will take to paint any individual room. And real engineers, indeed, have this same issue with the design phase of projects, for the same reasons. Just like us, they try to break apart and estimate how long it will take to do that part, but just like us, my impression is that it is known to be fraught to accurately estimate that part of a project. But also just like us, this is a continuum based on how novel the thing they are engineering is to them. On the one end of the spectrum, there is the equivalent of off-the-shelf software, like using a blueprint for a standard single-family home that's been built a million times already. And on the other end of the spectrum are things like designing the motor for the first model of a new electric vehicle manufacturer, where it's all brand new. But then there's a whole spectrum between those two, where it is fairly easy to break down and estimate the design process for things you've done a bunch of times, and nearly impossible for things you've never done. This is a very long-winded way of saying that the difference comes down to how novel the project you're working on is! This is why freelance / contractor shops do best when they find a particular niche of a kind of thing to build, and then find clients who want them to build essentially the same thing over and over again. It really is possible to get very good at estimating this kind of nearly-cookie-cutter work. (I did this a bit for awhile back in the day, with multi-page Rails CRUD apps, and it was indeed easy to break things up and estimate.) But this is also why it can be frustrating to work with freelance / contract shops, because it behooves them to figure out how to fit your project into their cookie cutter, and that can end up being a worse outcome than building something bespoke, iteratively, without a detailed plan and estimate.

tonymet 3y ago

The best way to estimate is to start work and benchmark your progress against your estimates

swah 3y ago
Another post has this part: https://jacobian.org/2021/may/25/my-estimation-technique/#5-track-your-accuracy-so-you-can-improve-over-time https://jacobian.org/2021/may/25/my-estimation-technique/#5-...

roenxi 3y ago

This gets a lot of teachers - the task is so ingrained in them that the only part they consciously understand is the trivial bit that everyone already gets. Breaking down a task and estimation are almost equivalent - once the breakdown is done, assigning estimates to the chinks of work takes a few minutes as anyone with a few years experience has some standard estimates for small tasks. In my experience I break down a task by biting off chunks that I can estimate, then ask for opinions on anything I can't. Although I don't even believe the real path to mastery is the task breakdown. Anyone can come up with a bad breakdown. The real point of mastery, which he didn't talk about here, is identifying when the evidence suggests a task breakdown is incorrect enough to cause problems and communicating that / doing a re-estimate [0]. And being comfortable that it will happen so not getting stressed up front putting out a schedule that is likely to change. Managers generally want an accurate roadmap up front. This is them asking for the impossible. IMO Good management is about flexibility and understanding that the expected nature of the work changes as time passes and developers learn. He has a little example at the end. Ponder that if someone had come to him with an accurate estimate ("you can do this in a few evenings as a plane trip") he'd have rejected that as too risky. That illustrates that estimating isn't even about accuracy, there are many unspoken factors here around risk management, expectation management, task familiarity, etc, etc. [0] https://jacobian.org/2021/jun/8/incorrect-estimates/ https://jacobian.org/2021/jun/8/incorrect-estimates/ - he has a post on the topic

WaxProlix 3y ago
Really great, honest and refreshing link - my thanks for posting it.

teeray 3y ago

Breaking down work works great until the breakdown is unknowable. Things like research, that require creative experiments to POC things that are not known apriori. That’s when task breakdown breaks down.

winwang 3y ago
...and then you break out the actuarial models :) And at some point, you just gotta do it.
al_borland 3y ago
Also when management sees what should be a POC or research as a deliverable they start promising to higher ups and other teams. I’ve developed the habit of doing most of my POC work behind closed doors and telling no one. If it works great, I can release it. If it doesn’t, I can kill it and move on without having to eat crow, or get told I need to figure out a way to make it work after I’ve seen it’s not wise to continue.
- beebmam 3y ago
  I'm jealous that you have such flexibility at work that you can do POCs behind closed doors!
throwaway346434 3y ago
Nah, that's easy to solve. "spend 3 hours on investigating X, 3 on Y, 3 on Z"; and then have a planning session about what to do next. You have 4 outcomes - the first one solves it, the second, the third or none. If it is solvable with mild effort, you have a 50% chance of solving it by attempt 2/6 hours.
- n4r9 3y ago
  It sounds like a pretty small problem if you can build a PoC in 3 hours. Sometimes it takes 3 days to get to a point where you have a rough idea of what code changes might be needed.

itsgrimetime 3y ago

Maybe I’m just lazy/undisciplined/a cowboy but having to break things down into “pointable” tasks feels like busy work just so management can “see” progress. I mean, thinking through a problem you’re trying to solve before starting makes sense, and having rough milestones is important - but a majority of the time there’s so many unknown unknowns that fully breaking it down is totally useless, if not impossible. If I spent the same amount of time it took me to break a project down just working on figuring out a solution or building it, it’d get done way sooner. At least, that’s how it feels.

jsmeaton 3y ago
> feels like busy work just so management can “see” progress Lot's of people feel like this. I usually come at it a different way - we're trying to estimate effort to see if we want to attempt building it in the first place. Assisting with the cost-benefit question if you will. That's the first reason. It can also be extremely beneficial to the team, particularly when working with less experienced folks. You can farm out a lot of the work and parallelise the task. I suspect Jacob didn't do much of this breakdown when implementing his streak app, which is why he recurses in an illustrative way.
sateesh 3y ago
Ignoring management part, one place where I have found breaking down to be helpful is when I have to work on some thing which I am not terribly motivated todo (say it is boring, lethargy, or it looks too daunting). In such cases I have found it useful to break down to smaller tasks and keep completing each of them which in turn generates a momentum to continue, as I have been able to make some progress from a situation where I was essentially in a deadlock (or was lethargic to work on).
throw1234651234 3y ago
I mostly disagree with you if you work in a "standard" company - it's usually "make a form" or "move data / do some other CRUD". These tasks don't generally have that many unknowns. It's absolutely valuable for managers to be able to estimate velocity as well, though the problem is that they really do stop understanding "we are not sure" once you spoil them. I am a consultant too, so it's critical for me to say "we are delivering this, in this much time", even though we are "agile".

tareqak 3y ago

> Delivers change because, in a work context, a task only “matters” if something is different because of the work. I think maintenance tasks may require more effort / more expansive qualification when it comes to the meaning(s) of "something is different". I think the topic of "breaking down tasks" could very well be its own book genre or even podcast genre. My experience with self-help and organization titles has been that the activity of breaking down tasks is a sort of known primitive human operation that many authors assume their readers to have. However, my own personal experience and the accounts of others I have heard while participating in group sessions is that breaking down tasks can be very difficult and provoke emotions of avoidance and despair. The most broadly relevant advice that I have come across when it comes to breaking down tasks is to keep breaking things down until I am 90% certain that I can successfully complete the task. The certainty here would vary on how much self-confidence an individual has and their risk tolerance, so some people may break down tasks to 70% certainty of success.

XorNot 3y ago
The problem I have with task breakdowns is you get way too much engineer overconfidence - i.e. there is literally no task which is less then an entire day's effort, in practice. There's about 6 usable hours in a day - I've watched people confidently bid they'll get something done in "half a day" but when you point out that's about 3 hours, suddenly they're way less sure about that number - or offended. Then 3 days later they're still working on it.
- devsda 3y ago
  Sometimes it is not overconfidence but a side-effect of management interference & second-guessing the estimates. In this case engineers give an estimate of what they think management wants to hear and not the actual time it takes. It happens if they are frequently asked to reduce their estimated time to within management expectations. To deal with this, you need to bargain with them in the opposite direction to make sure the estimates are realistic.
  - bruce511 3y ago

m3kw9 3y ago

Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown

petersellers 3y ago
Isn't it more likely that you can catch yourself during the planning phase if the amount of work being estimated exceeds your budget? That seems much cheaper and easier to pivot from than if you were to make that realization halfway through your implementation.
- m3kw9 3y ago
  I think it’s par for the course because you can only plan so far before you run into miscalculations once you start doing it. You break down tasks for stuff very close range
lelanthran 3y ago
> Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown Similarly, if you don't plan enough, and get far enough into a small project, you don't change your approach because of the sunk cost fallacy.
- m3kw9 3y ago
  Right, you are susceptible to it either way. In that case breaking down a task can potentially get you way further

hnaccountme 3y ago

Software development cannot be managed like this. This sort of task break downs come from classic management training. The problem most people are unaware of is software development is more a creative activity than anything else. Yes there are serious technical aspects to it but since the problem is virtual and not bound by any real world limitations, like how civil engineering would be, there isn't one optimal solution. Trying to define the solution before the problem has been properly examined would only limit the final output. Most of the exploration only happens when people actually start coding. Not having a well defined final output and time is not very relevant for software, mostly because there is no per unit cost. Most managers do not realize this is they are not from a software engineering background. A versatile product can be sold to many different customers without additional development costs. But since most companies are managed as factories, all the processors will ultimately create a very limited product targeted at a specific customer. What the big tech companies have avoided is this .

rolisz 3y ago
You'd be surprised how much creative tasks like 3D modeling and creating artwork can be broken down into tasks that are very well defined and can be estimated quite correctly.
- makeitdouble 3y ago
  I think it would fall down the same lines if you required a coherent world and high quality for each of the models you create. That would mean redo models that don't fit the whole piece, endless tweak some models that are really difficult to get right, sometimes do swiping changing across all the parts because as a team you realize something is off etc. The balance will be between delivering something within a time frame, and delivering the quality that was requested/expected.
- heisenbit 3y ago
  The difference is that you break down software into smaller and smaller bits and then find a small bit that needs data from a far away small bit. I suspect this happens less with mechanical systems.

082349872349872 3y ago

compare https://shitpost.plover.com/o/omega-omega.html https://shitpost.plover.com/o/omega-omega.html

Scarblac 3y ago

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make something is put in the first part. And then, the rest is still most of the work, but it's the really boring part. It's much more fun (and therefore faster, and resulting in better work) to spread the creativity and the boredom out more equally. The two are probably related, and it's not inconceivable that I have ADHD.

suslik 3y ago
I am somewhat like that myself. I do formulate a plan and break down tasks in advance, but I give myself an absolute right to change and modify it at will whenever new ideas come to light or just because I'm feeling like it.
Rygian 3y ago
> the plan is never followed The plan not being perfect and prescient is part of the plan. Next time you plan for same or similar activity, your future plan will be better. The Project Managers even have a mantra: "fail to plan is plan to fail."
- Scarblac 3y ago
  And Eisenhower's "plans are useless, planning is essential", of course. I know. But for me it's very easy to overdo it. Give me interesting chunks of about a week or two, with a tight deadline, and I'll do my best work. Remember, Linus wrote Git in two weeks. And there was no project manager in sight.
  - baliex 3y ago
    On the Linus point, I'd bet there were countless months where he was bringing ideas together in his head and planning how he'd do it before actually finding the time to sit down and write it.

TomatoDash 3y ago

Good read! I wish we had a shorter name for "breaking down tasks". Perhaps taskspec, short for "task specifying". Or taskdev?

swah 3y ago
"refinement" in JIRA world I think

segfaltnh 3y ago

A lot of the "never taskers" in this comment section seemed to have never worked with the juniors I have. These are good, new software folks who genuinely don't know how to stand up basic functionality because the space is new to them. In my experience they want tasks they can learn from and excel at, leading to growth. I think the thing that you absolutely must keep in mind is process overhead is a continuum you tune to your team. No one in the NBA is going into a huddle and getting instruction on how to throw a ball mid game, but the kids in third grade are. Both styles of planning and coaching are appropriate to the team at hand.

globular-toast 3y ago

What's missing here is who this breakdown should be shared with. There are three levels of breakdown and the details of lower levels should never be revealed to higher levels: 1. The "business" level. There are no "tasks". There are only needs and desires. Things like "a user can log in and press a button". These should not be broken down further than the smallest unit of deliverable value. In this example, there's no point estimating "user can log in" because it delivers no value on its own. A good rule of thumb is these should be described using descriptive language, not imperative, so not e.g. "implement log in procedure". 2. The "team" level. It's OK here to break down those things into "user can log in" and "logged in user can press button". That's because you know they can be implemented independently. But there's still no point delivering them independently. Don't tell the upper level about this breakdown. They are always really eager to know, but they don't need to know. Use this to calculate your estimate for level 1, but said estimate should be a single aggregate. Implementing these in parallel with multiple devs adds no extra overhead because they are completely independent. 3. The "developer" level. This is where you finally have "tasks" and imperative language. Things like "add button to form", "implement 2FA" etc. These tasks are naturally heavily dependent on each other and it's highly likely they'll be done in a completely different order to whatever you write them down in. If you decide to distribute these tasks among developers then you increase the coordination overhead between devs. Think of it like a multi-threaded application. It's always more efficient for a single developer to do everything if possible (less overhead), but it might nevertheless be necessary to split it up due to time constraints, differing skillsets etc. It's just like we'd like to have one single 80GHz general purpose CPU, but in reality we have to make do with 16 5GHz cores split between performance and efficiency cores etc. Given that the tasks are highly likely to change and evolve, there is not much point putting in loads of effort to break things down. Do it only when it's necessary, or when it helps you. It's necessary when you need to split up the work between developers. It's helpful when you think of more tasks during your work and you don't want to break your stack. Every developer should have a way to quickly take notes in a way that doesn't break flow, things like "ensure API accepts float input". This is stuff you'd never think of before you get your teeth into it.

firewolf34 3y ago
Can you elaborate on why we wouldn't share the carefully estimated project plan breakdown with Level 1? I'm not disagreeing, just curious - one would think that with doing all the work to achieve a solid project plan breakdown and Gantt charts and such, it would behoove you to express this to management who is salivating over tangible examples of progress... I understand we don't want to show technical to non-technical, but part of the good project plan is the fact that we can show a roll-up of the tasks, so the abstraction is visible. It's hierarchical.

ChrisMarshallNY 3y ago

This reminds me a bit of the old "Write a story about the task. The nouns are objects, and the verbs are methods." method of OOP. I never warmed to that. However, this is not that, and I think it's an important skill. I started my professional life as an RF technician, and we learned how to do this, almost immediately. We used things like signal generators and oscopes.

deleted 3y ago

[deleted]

alkonaut 3y ago

The biggest problem I have with splitting tasks is reluctance to do duplicate or unnecessary work. Breaking down tasks into smaller tasks means you must do duplicate work. The trick is to minimize it. If you try to make no unnecessary work, you'll end up having to do everything at once. Example: you want to refactor a program with two modules A and B where B depends on A. The least wasteful way of doing it is to refactor both modules together. But it's also the riskiest and hardest to estimate. The broken down way is to refactor A and adapt B so that it works with the refactored A. After that you would refactor A, which would then risk making the adaptation effort very short lived. If you want to do zero throwaway effort, you often can't break down the task. I have 20 years of experience and I still often find myself reluctant to do throwaway/temporary job in order to divide work. Instead I find myself doing multi-week efforts with zero yaks left unshaved.

throw1234651234 3y ago

Does anyone have a better article on this? This is ok, but it seems like there are better - I would love to share with my team. These are things I always share with them: On code reviews: https://mtlynch.io/code-review-love/ https://mtlynch.io/code-review-love/ On simplicity: https://grugbrain.dev/ https://grugbrain.dev/ On SOLID (even though we use Python now): https://www.baeldung.com/solid-principles https://www.baeldung.com/solid-principles I would love to have a "standard" article for planning.

nate 3y ago

Being a career long engineer, I'm not unaccustomed to breaking down huge projects into smaller things that can be parallelized, plotted in time, etc. We have to do it and get better at it. But honestly, I think what holds most of us back is a better ability to just don't do that. Take that thing you want to make, and instead of planning out all the pieces, just make the tiniest possible thing that could possibly be of value. Using this example, just start with "Today" and the 4 buttons. Make a thing that shows your 4 buttons of exercise you will click on each day. You can probably make that today. No streaks or freezes or calendar view. Those are all great ideas, and you'll get to them. But you need momentum. And you'll probably decide you don't even like that calendar view in a few days. I think more projects need a kick in the pants of just do something small. Get it done today. See what the next task is from that point because it's probably not what you thought it ought to be during the planning phase. This also isn't exactly easy either. It requires some thought and discipline and find the smallest thing and commit to shipping it without distraction. But it's also something good to practice at.

sanderjd 3y ago
I have come to think of this as "The Anna Principle" in organizing my own work: > when faced with uncertainty, one must simply focus on doing "The Next Right Thing." [0] This is not to trivialize it! Figuring out the next right thing to do is hard, but also the most valuable part of planning, in my view. 0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
- rhapsodic 3y ago
  "Do the next right thing" was a phrased used by Alcoholics Anonymous long before that 2019 movie came out, so I don't think calling it "The Anna Principle" is appropriate.
  - sanderjd 3y ago
    I didn't know this! That just makes me appreciate this more, and thank you for making me aware of it. But thinking of it as "The Anna Principle", named after a character from a children's movie, remains way more fun. It was already a tongue-in-cheek-ism to ascribe what I really do believe is a strong foundational idea (not just in project planning, but in life) to a character in a children's movie. By the way, I tracked this back to at least one earlier use of a similar construction (which maybe is implied to be the basis of its use in AA) by Carl Jung: > But if you do with conviction the next and most necessary thing, you are always doing something meaningful and intended by fate. Excerpted from: https://www.themarginalian.org/2021/12/07/carl-jung-next-right-thing/ https://www.themarginalian.org/2021/12/07/carl-jung-next-rig... But I suspect this is an even older, indeed timeless, idea. But ascribing it to a modern well-known movie character makes it more fun and memorable :)

swah 3y ago

Meta: any other blogs like this one? I really enjoy the writing, the topics..

alexakten 3y ago

I created tasktree.co for myself to help with this! It’s so easy to get overwhelmed when faced with a big task, and actually forcing yourself to just break it down helps a lot.

deleted 3y ago

[deleted]