Live data from Hacker News

Breaking down tasks

jacobian.org

101–110 of 118 posts

Re: Breaking down tasks

#101
post #92

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 o…

This is typically called a PoC or MVP - shouldn't this also be scheduled and forecasted?

Re: Breaking down tasks

#102

Earlier quoted context omitted.

I think making plans/planning needs training to be good at - which in turn reduces "overplanning". Knowing what to include, discuss in which forum, what task or deliverable granularity, etc. is useful doesn't come naturally to most.

Agreed. But actually, I kind of feel like people who have had training to get good at planning, are not the most likely people to be good at avoiding "overplanning". I think it's the same kind of incentives as how dentists have a natural bias toward recommending dental work, or chiropractors toward recommending adjustments, or programmers toward recommending writing software, or anyone toward doing a bit more of what…

I think that happens typically when the planning and the execution are very divorced (someone good at/selling using the techniques of planning). I'd say a good operational planer doesn't overplan.

Re: Breaking down tasks

#103
post #92

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 o…

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

"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.

Re: Breaking down tasks

#104
post #101
post #92

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 o…

This is typically called a PoC or MVP - shouldn't this also be scheduled and forecasted?

Yes, definitely thought of that way most of the time. But I also think that might actually trivialize this concept some. Because one might say "ok, here's the crappy MVP version, and now that we're out of that one month phase everything after requires very rigorous and careful planning and meetings". I think most projects actually need to just stay in MVP mode. The entire project or product will be forever in a place of high uncertainty. Every feature should feel like it was the minimum we could do.

I'm actually not saying every project needs this of course, but I think maybe most might? Obviously there's huge things I've been apart of, and we needed to be thorough planning step by step months out. But that experience should probably be the exception and not the rule. Minimums the rule.

Re: Breaking down tasks

#105
post #92

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 o…

I find that this attitude is also great for life in general.

Absolutely. I mean, yes, there's those moments where you need to plan your retirement and you better think 40-50-60 years out. But most of the time, just do the next 5 minute thing and see what happens. I've been getting a lot better recently about just coming up with 3 "quests" I'm going to do today that probably take 5 minutes. And that little progress has kept building and building into something I didn't really see months ago when I started that first 5 minute step.

Re: Breaking down tasks

#106
post #92

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 o…

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

OMG, I love that you put Frozen 2 and princess Anna and a song onto this. Thank you for this coinage. I will absolutely be using this now. Please write a blog post on your coinage of this so that we all here can link to that and give you some credit. I'm serious. I looked up The Anna Principle and I wanted to see your blog on this.

Re: Breaking down tasks

#107
post #92

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 o…

One thing that works for parallelization in these unsecure situations are things that you know you'll surely need. This even might just involve testing things. E.g. on member developes a comparison method for testing, another member goes for one approach, another for the other and a third for yet another. And after a set period you try to evaluate everything. Of course this approach only makes sense when there isn't already a favoured or clearly superior approach.

Similarily during actual development modularization can be a way to parallelize development. So one component per person or per team.

For my own stuff I also like to interleave the human-facing parts of my products with the technological guts, especially if I am still figuring things out — developing the technology without knowing how it is being used will force the way you can use it into a certain direction — designing the interface without knowing the technology has it's own traps as well.

Re: Breaking down tasks

#109

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 someth…

I also can't get myself to do it seriously for my own tasks, but when I had to do it for a jr colleague I found out... yeah, breaking it down its hard, as hard as coding - then you get most of the hard work already done, and coding the solution becomes trivial. Chances of false starts go from 80% to 20%.

(A few times there is prototyping involved but I won't share that with non-devs, since they don't seem to get it.)

Re: Breaking down tasks

#110
post #2

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.

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?

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.

Post reply on HN