The Old New Thing

Traveling down this road we will ultimately end up with the highest possible priority of all, Priority Negative Infinity.

At least until some jerkwad comes up Priority Negative Infinity Minus One.

Just wait for Priority Yesterday!

@John, Darren:

No, no, no. In a year and a half, all the consultants come around and insult you for backtracking to Zero and Now, and they turn the whole thing around so that you use a scale of 1-10: Priority Ten is the top, Priority Eight is "still pretty important", and Priority Five is the nice-to-haves. (And Priority One becomes the "fine, we'll put your story on the board, but it'll never happen" bucket.) That'll be $30k in consulting fees, thanks.

This has the added bonuses of giving you plenty of room to easily expand ("We need a 'Priority 11' for 'we have to fix this now' issues", followed rapidly by Priority 12 and Priority 14) and setting a precedent for the consultants to come around again 6-7 years later and reverse it to 1-3 for another $55k.

I believe priority 0 items were created when people who had issues that should have the same priority level as 1 but they themselves didn't feel that way, used bureaucratic ways to make others think their same way.

Also, priority level 0 makes sense as a key in an array. But priority level -1 should start you off at the opposite end :P So it doesn't work quite as others would hope for :)

Priority -1 is just silly. My team uses P0 thru P2. I think our tool actually accepts P3, but I've never seen it used.

More granularity in a system like this is actually bad: it implies that you're able to make distinctions between a P5 and a P6, when in reality you're just guessing at that point.

Personally, I always loved priority "Never".

Wonder what would be the next priority level after "Now", though. Possibly "Yesterday"? Or simply "If you are reading this, you're fired" priority?

Priority Now is a great name! Unfortunately, it won't last: MS Marketeers are famous for turning great codenames into awful official names.

Some groups have started using priority 00 or P00. Now isn't that clever, or just sad, and a little bit funny.

In my old group my manager told me some feature was priority 1A, which was his version of Priority 0.  Later on he came up with an actual Priority 0, leaving us with the curious scale: Priority 0, Priority 1A, Priority 1, Priority 2, Priority 3, and Priority 4 (yes there were actually things ranked at P4 on that scale.)  Ah, the good ol' days of 2001.

Women's clothing has a "size zero" for much the same reason. The sizes kept getting bigger to make women feel better about themselves: "oh even after eating that whole hog I still fit a size 6!" that now women who are truly petite are actually off the scale. It's crazy.

In terms of a non-shipped product P0 makes no sense, but in terms of hotfixing one that's been shipped there is a use - identifying the one and only top category priority item that must be done next.   Now, of course, this gets abused, and becomes useless if there are more than one, or more than one per developer.  But there you have it.   A simple 'currently highest priority' flag would also work.

As for P4 items, I vaguely remember them being used to indicate stuff that was known bugs/issues that someone had investigated, but there were no current plans to fix. This was just a convenient way to keep the history of them in the tool, in case they ever moved up in priority.   If the current version was SPn, they were targeted at SP(n+2), and as each SP released someone would go and retarget them all.

Same as car inflation. Every next year model gets bigger, gets more legroom and cargo space, and before long, what used to be a compact sedan becomes an medium model, and medium car becomes large.

This actually happened to my previous company (now 10 years old).  Originally there was no such concept of priority...  a bug is a bug.  Then, Low, Medium, and High are introduced, say around year 3.  In year 5, Urgent is added.  In year 6, Critical is added.  Now everything "important" is critical.  urgent means important but not deal-killing.  High is equivalent to the original Low.  Medium usually means something an engineer want to work on in his spare time (i.e. pet project).  You'd think that Medium and Low will never be worked on.  That's not true.  They do contribute to one metric that some pointy-headed cares about: number of bugs fixed per month.  I have also seen artificially created "non-bug" designed to bump up such number.  Welcome to the world of software development.

I think, more like what i use in my personal notes, is that Priority 0 is what cannot be categorized or the small things that u can just do as a 'quicky'

I guess we're doing pretty good - I've only seen pri 0 in planning documents to refer to features that are already completed, but still need to be tracked for whatever reason.

Of course, we use pri 0 for other issues, but it just indicates blocking problems: P1 = must have, P0 = must have NOW.

Priority 00 made me laugh and think of Priority 000 which reminded me of the "rock machine" se studied in school.

Then the whole priority system can be considered Turing-complete!

Priority Now.  Priority Now. I can imagine Estelle Costanza screaming that in her shrill voice as Frank Constanza confronts her, red faced, and yells back, "Serenity Now, Serentity Now."

When I used to be responsible for part of the build of Windows, there were several (very, very bad) days when builds were broken across multiple disjoint groups for different reasons.  It was always great to get those emails where the sender told me "this is your priority 0, and I want an answer now"; I always had to bite back the urge to just respond with "I've already got a few of those.  Get in line."  This was particularly true when the latest person with a problem was in a relatively minor branch -- I know it was important to them, but if the main branch was broken, they're nothing until that's fixed.

At the part of Microsoft I work at, we run a large hosted service with a very high reliability SLA, and we typically use P0 for a very specific reason: is this bug worth waking people up in the middle of the night to look at? This usually means something like our services are totally unavailable, or severely broken.

for regular software development cycles (working on something that will ship in the future), we don't use P0. Our definitions roughly match what the article says (our bug system has a P4 which we never use). P1-P3 also map pretty well to a production deployment of a system, but it is useful in that context to have a P0 which means "it's broken right now and customers are mad."

Can I be the devil's advocate here?  I think you very nearly justified it in the OP; "Maybe 'If we don't do this, the earth will explode.'"

It's not quite that extreme, obviously, but I see "Priority Zero" items as things that are not just risks to their own project, but to the customers or company as a whole.  Things that could get you sued, for example.

If you woke up one morning and Word's printing functionality was broken, and it also appeared to be opening up an externally-visible server allowing modification of system files, what would you do?  They're both deal-breakers.  But one means Word is useless and the other means it's *damaging*.  Fixing printing is priority one.  Closing the security hole is priority zero.

"But Pierce," you might ask, "why not just call the security hole 'priority one' and printing 'priority two?'"  Well that's where the politics come in, and as arbitrary as it is you cannot call a feature like printing in Word "priority two."  If you look at it logically there's no difference, but large organizations have a lot more influences than cool logic.

I don't understand the system at our company.. we have priority 1 to 5, and severity 1 to 5.  Then, there is a flag called 'show stopper'

But people prepend 'showstopper' in the name of the bug, so we can find them more easily, and that takes precedence.

There is also another number to order the bugs for the developers, by priority.

It degenerates to being that there are showstoppers and non-show-stoppers.

At work yesterday, we were discussing the representation of a diagram showing a list of 18 different issues. Initially they were shown as equal segments in a circle, which resulted in the complaint that it looked like a pie chart thus implying all 18 were equally important. My suggested solution was to hire MC Escher to draw the diagram such that every item was larger than the next...

(Come to think of it, I suspect that was actually the most viable strategy we could come up with. That's academia for you!)

Yeah - um - There are High, Medium and Low priorites. I've never shipped a Low. If it's important enough to ship, it's important enough for someone to negotiate it up to at least a Medium.

In my experience priority-0 bugs are generally top-down bugs that effect (or are perceived to effect) the company as a whole.  The loss of a project is bad, the firing of a few peon programmers isn't great, but the loss of the company or the company's reputation is significantly more important and thus rates higher than a bug that only effects a single product, regardless of how terrible that bug may be for that product.

Nigel Tufnel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and...

Marty DiBergi: Oh, I see. And most amps go up to ten?

Nigel Tufnel: Exactly.

Marty DiBergi: Does that mean it's louder? Is it any louder?

Nigel Tufnel: Well, it's one louder, isn't it? It's not ten. You see, most blokes, you know, will be playing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar. Where can you go from there? Where?

Marty DiBergi: I don't know.

Nigel Tufnel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?

Marty DiBergi: Put it up to eleven.

Nigel Tufnel: Eleven. Exactly. One louder.

Marty DiBergi: Why don't you just make ten louder and make ten be the top number and make that a little louder?

Nigel Tufnel: [pause] These go to eleven.

Priority inflation is always going to happen, so I always advocated reversing the priority scale and making P3 higher than P1.  That way when you start the next version, you simply admit up front that P4 exists and work with it.  When you start the next version and create P5, you can automatically close all the P1 bugs as "won't fix".  If it made it through two releases without being fixed then it just doesn't matter.  

This is why having the feature backlog as an ordered list, as in Scrum, is so much better than trying to attach discrete priority values to items. Much pointless discussion over whether a feature is a low-1, a high-1 or a zero can be avoided. Any two features can be compared to assess which is more important; apply a sorting algorithm of your choosing. No priority inflation here - just start at the top of the list, work down, and periodically re-sort as priorities evolve.

There's a similar trend with levels in logging systems. The basic four are:

* error - something went wrong and prevented an operation from completing

* warning - something went wrong but it did not prevent the overall operation from completing

* info - auditing information, such as a change in password or a user logging out

* debug - useful only for developers attempting to figure out what path the program is taking

At a previous company there was a logging system that had these four classifications but also had three "significance levels" within each classification, so you could say "show me all errors and all warnings, but only show me really significant info and really significant debug". I assume the goal here was to allow you to turn down the vebosity of the logs to only see higher-level log messages, but in practice the distinction was pretty arbitrary and so it was rarely useful to filter by this number.

I notice log4j has fatal, error, warn, info, debug and trace. I don't know what the difference is between fatal and error and between debug and trace; they sound similar to the significance levels I described above, but they've bestowed some of the significances with names.

I've never needed more than the initial four I listed, personally. In practice, my configuration only cares about three cases: error and warn get batched up and sent to be via email, info just goes into a log file and debug goes either into a log file unless the app is running in production.

I think the lesson here is that regardless of what you're describing there's little point in adding more levels unless you can concisely describe the difference between each level. As soon as you have a level that takes more than a sentence to describe, or that's just defined as "more important than level n+1" you've got too many levels.

The same thing has happened to the grading system for the GCSE exams in England.  Too many people were getting Grade A (government says it's obviously because the education system is improving) so A* was introduced to distinguish between 'a really awesome level of A-ness' and 'just a plain-old, pretty-standard A'.  Someone mentioned A** to me the other day, but I can't confirm whether it was a joke or reality (yet!)

As it was said in other comments P0 actually makes sense for teams that develop online services. P0 is used for live site issues requiring hotfix, P1-3 are used for next release fixes/workitems.

In my experience:

Pri 0 - If you don't accomplish a pri0 item, other products that have dependencies on your product can't ship.  May also represent preliminary work that must occur before the majority of the team can start on a project.

Pri Now - A large portion of your product team needs this to be completed before they can make further progress.  Can occur as a result of improper planning (ie:  crap, our spec has a fundamental flaw that needs to be fixed), though more often seen after the planning process as blocking bugs (ex: the test team can't test the product because there is a bug that causes it to crash on startup).

In my experience, P1-P3 apply to a milestone, ie. the milestone can't ship a month from now if you don't fix/implement the P1 issues.  But P0 (I haven't seen PNow) means that something is broken that needs to be fixed now, ie. the team gets blocked tomorrow unless it's fixed.  In other words, it's a little bit "orthogonal", since it's really a P1 bug with an extra bit that indicates a need for immediate attention.

At some point, I'm sure we're going to skip the whole scale of 1-3 (0-3) and start calling them Priority 2008, Priority 2009, and Priority/Next Generation. :)

The whole priority language is incoherent, even ignoring priority inflation. What is "high priority" Is it high numeric priority, indicating lower importance, or the opposite? Why not just number priority levels such priority N+1 is more important than priority N?

> Just wait for Priority Yesterday!

Emmm... Am I the only one thinking about the "Status, Please" entry of WDWTF? :P

http://thedailywtf.com/Articles/Status,-Please.aspx

I think an important thing about being agile a great developer is to make sure your backlog is correctly

I think you need more than three:

0. Do this now. Other people are blocked. Seriously, drop what you're doing, and get on this now, and don't leave the office until you've fixed it.

1. Do this before release. If this isn't done, it's not getting released.

2. Should be in the release - in extreme circumstances it can be bumped to the next revision.

3. Nice to have if we have time, but not critical.

Hmmm, so priority zero means critically important?  All this time I've been thinking that priority zero means that it has no priority, and therefore doesn't have to be done at all.  Whoopsie!

I agree with Sebastian, and that's what my current company does.  P0 means that something that effects current customers is broken--the servers are down, harddrives are being formatted, etc.  It means you can't go home until its fixed.  And it is a very rare thing to see a P0 bug.  Sometimes P0 bugs get opened by PMs who think they have a very important feature to get done and they quickly get triaged to P1 (or less).

@John: That's why we should use ordinals and give high ordinals to high priorities.

Priority n+1 means it should be done before priority n.

Priority omega is a priority higher than any other integer priority.

Priority omega+1 is a priority higher than priority omega...

Priority 2*omega is a priority higher than any omega+n priority.

Priority omega^2 is a priority higher than any n*omega+m priority.

Priority omega^omega is a priority higher than any omega^n priority.

And so on.

PingBack from http://polymathprogrammer.com/2008/11/26/here-come-weaker-viruses/

Priority 3 - nice to have

Priority 2 - should have

Priority 1 - must have, or get fired

Priority 0 - must have, or go to jail