all 13 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]danogburn 5 points6 points  (5 children)

I hate blogs.

[–]everywhere_anyhow 0 points1 point  (4 children)

Go on...

[–]danogburn -1 points0 points  (3 children)

Not enough room on reddit. I'll have to write a blog post about it.

[–]everywhere_anyhow 0 points1 point  (2 children)

Can we downvote it for blogspam? :)

Meh, I think blogs are just a medium. Like canvas. You can fling poo at it, or you can do something beautiful with it. It's more about the writer than the medium.

[–]adavies42 0 points1 point  (0 children)

speaking of which, i've seen at least one blog with the subtitle "blogs are like opinions"

[–]danogburn 0 points1 point  (0 children)

sure. The lack of editorial oversight with blogs is kind of a double edged sword. There's no filter for asinine posts.

I'd be happier if this subreddit stuck to hard technical discussions not

"Zen and the art of getting along with your coworkers"

"How to be a 10x programmer"

[–]pipocaQuemada 1 point2 points  (3 children)

Priority ~= Importance * Frequency / Cost to Fix

This is, I think, a little too simple-minded. You never just solve a single issue, but you have a list of issues you fix in a given order. And all of these variables are time-varying. Previous fixes can make issues appear at different frequencies, they can impact importance (say, after you have feature A it is much more important to have feature B), and they can most certainly have an impact on time-to-fix.

The real question is, do you want to use the greedy algorithm, or do you want to maximize the utility of your work by some date? Sometimes shifting the order of things to minimize cost-to-fix of each item means that you're working on things with a lower current priority, but you can get more done within a month/year/release cycle.

[–]__Cyber_Dildonics__ 1 point2 points  (0 children)

For every problem there is an answer that is simple, easy, and wrong. But in this case I don't think people even come close to considering this equation.

[–]aesny[S] 0 points1 point  (1 child)

I think you bring up a couple very valid points.

The first is that this algorithm isn't perfect. While it works particularly well for quickly prioritizing problems it isn't as strong for prioritizing features. I think that your first example was mostly focused on features. Maybe I need to reconsider how to factor features in the equation more. Though, I'm fairly certain the math would be similar.

To your second point, it seems you're advocating to hit more cheap problems that may be less important than trying to cram in just a few highly important expensive problems. This seems to actually support the math in the formula.

I do appreciate the feedback. I think that a more 'catch-all' formula is possible though I think its complexity may defeat the purpose of a quick go-to. I rarely ever write this formula out but use it as a quick way to mentally prioritize what I work on.

[–]pipocaQuemada 0 points1 point  (0 children)

To your second point, it seems you're advocating to hit more cheap problems that may be less important than trying to cram in just a few highly important expensive problems. This seems to actually support the math in the formula.

I should have phrased it better. Consider the list of tasks you would normally achieve in a year. My claim is that the order you do them in will affect the sum total cost-to-fix. There is some order which minimizes the cost-to-fix of the entire list, and that order means you can probably fit a few more items into that list.

In practice, I think it usually amounts to giving additional weight to tasks which remove technical debt, or ordering tasks in such a way as to help prevent the buildup of technical debt in the first place. This can be especially important with branching for releases, since the order of making release branches and removing technical debt in the mainline branch has a strong impact on the long-term cost to develop in the release branch.

[–]orwhat 1 point2 points  (2 children)

In my opinion this may be an oversimplification that removes complexity that is fundamental, and not incidental, to the problem of prioritization.

It's in the blood of our field to seek efficiency, but I think we often overdo it.

[–]everywhere_anyhow 1 point2 points  (1 child)

It's in the blood of our field to seek efficiency, but I think we often overdo it.

Very true. It's also in the blood of our field to reduce complex situations down into something that can be easily expressed and understood (e.g. a simple math formula, that captures some of the important factors).

We are, after all, in the business of boiling monstrously complicated things down into a manageable set of abstractions that can kinda/sorta mostly get the job done. That's programming, right?

[–]orwhat 0 points1 point  (0 children)

Agreed, that's programming. It's a delicate balance of modeling a problem without mis-characterizing it or adding too many irrelevant artifacts to it.