Re: The curse of the prioritized TODO list
- On 16 Aug 2002, Oleg Goldshmidt wrote:
> Omer Zak <omerz@...> writes:Interesting. I don't remember seeing that. Can you give specific URLs?
> > Now, to the crux of the matter. What criteria do you use to prioritize
> > the items in your TODO list?
> > Given two items, one of which is very important for one small customer,
> > and another, which will allow you to increase your sales by 100%, but is
> > not important to any of the existing customers - which one gets higher
> > priority?
> Recalling my experiences in one (big, multinational) company, here is
> roughly what the priorities were.
> - Nothing had higher priority than "production bugs", i.e. problems
> affecting the current operation of the system adversely.
> Despite this rule, at times bug lists for some functionality grew,
> due to one problem or another (personnel, serious screw-ups,
> etc). When that happened, at some point a decision was made at some
> level (sometimes at the most senior one) that *no* effort would be
> invested in new functionality until the bug list was reduced
> essentially to zero length (in practice, you always expected a few
> not very severe bugs at any one time, it was a really big system).
> - After that, the most important prioritization criterion was (some
> measure of) additional projected revenue resulting from new
> functionality, but taking into account the available resources and
> the extent of development effort. In general, rather sensible
> In a small R&D group I was a part of, there was an additional local
> rule: we had a design review team that consisted of three most
> experienced people. Everybody (incuding the review team members) was
> expected to request design and code reviews from at least 2 members of
> the team at different stages of any project. The review team was
> expected to give such requests the 2nd highest priority, the 1st being
> fixing production bugs in their own code.
> I don't know how typical or exceptional this system of priorities was,
> but in this case existing problems were definitely given high
> It is clearly not the case always. I was rather amazed (or was it
> amused?) to see numerous instances of
> "Yes, it's a bug. We know it is a bug. Last time we looked at it was
> April 9, 1997"
> in MSDN/VC++ documentation. ;-)
In any case, I remember seeing that using _beginthread() and friends while
using Win32 calls may lead to small memory leaks in the program.
> Oleg Goldshmidt | ogoldshmidt@...
> "... Of theoretical physics and programming, programming embodied
> the greater intellectual challenge." [E.W.Dijkstra, 1930 - 2002.]
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Shlomi Fish shlomif@...
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@...
"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"