Subject: The curse of the prioritized TODO list

From: Omer Zak <[email-masked]>
Date: Thu, 15 Aug 2002 14:07:13 +0300 (EET DST)

If you want a software package to be able to perfectly fit your needs, it
must be Free Software.
The ultimate reason for this is the "curse of the prioritized TODO list".

How does it look like?
Let's switch sides.  Suppose you are a software house, which developed a
popular and useful software package.  Lacking any business model allowing
you to make a profit while letting your customers access and modify your
software's source code, you sell the software as closed source.

Your customers find it useful and pay you the price, and actually use it.
Since they actually use it, they come up with all small ideas for
improving the software so that it'll serve them better.  Some of the ideas
are bug reports (a bug is a problem only if it causes, or may cause,
an actual operational failure).  Other ideas are suggestions for
improving and extending the software package.

What do you do with all those ideas?  You love your customers' money and
goodwill too much to simply redirect all those suggestions to /dev/null.
So those ideas end up in a TODO list in your organization.

Obviously, all the ideas are not equal in utility, profit potential or
effort.  Therefore you prioritize the TODO list.  You and your
subordinates work on the top-priority items.  Ideas, which made it to the
top of the TODO list are acted upon, and make the corresponding customers
very happy.

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?

If you had been born to billionaire parents, maybe you would be a nice guy
and take care of the needs of that one small customer, even if you need to
hire 10 more programmers for this.

But if you are a normal business proprietor, who is paying off a mortgage
on his home, saving money for his children's future dwelling needs, and
renegotiating your business' bank loan each three months, the second idea
will get higher priority.  Thus, that one small customer will be very
miserable.

Once the priorities are set by business needs (including strategic
business directions), there may be no relationship between the current
user's needs and the priority of improvement ideas, which are actually
improved.

Thus, Microsoft may decide to implement ideas, which actively burden
customers (for example the Windows XP Activation mechanism) - because they
improve the software house's bottom line.

This is the "curse of the prioritized TODO list".

If, on the other hand, you (as a customer) chose a Free Software solution,
then improvements important for you don't get caught up in the vendor's
prioritized TODO list.  You may implement those improvements on your own
according to your own prioritized TODO list.
                                             --- Omer
There is no IGLU Cabal.  It needed some vendors to implement certain
improvements.  But those improvements were very low in the vendors'
prioritized TODO lists.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: Oleg Goldshmidt <[email-masked]>
Date: 16 Aug 2002 10:22:12 +0300

> not important to any of the existing customers - which one gets higher

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

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

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. ;-)

-- 
Oleg Goldshmidt | [email-masked] 
=================================================================
"... Of theoretical physics and programming, programming embodied 
the greater intellectual challenge." [E.W.Dijkstra, 1930 - 2002.]

---

From: Shlomi Fish <[email-masked]>
Date: Fri, 16 Aug 2002 21:38:59 +0300 (IDT)

> in MSDN/VC++ documentation. ;-)

Interesting. I don't remember seeing that. Can you give specific URLs?

In any case, I remember seeing that using _beginthread() and friends while
using Win32 calls may lead to small memory leaks in the program.

Regards,

	Shlomi Fish

> To unsubscribe from this group, send an email to:
> [email-masked]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"