Loading ...
Sorry, an error occurred while loading the content.

The curse of the prioritized TODO list

Expand Messages
  • Omer Zak
    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
    Message 1 of 5 , Aug 15, 2002
    • 0 Attachment
      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
    • Chen Shapira
      ... A very large part of my job is to recieve requests from customers, and prioritise them from RnD. I m proud to mention that when prioritising, existing
      Message 2 of 5 , Aug 15, 2002
      • 0 Attachment
        >
        > 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?


        A very large part of my job is to recieve requests from customers, and
        prioritise them from RnD. I'm proud to mention that when prioritising,
        existing customers always get higher priority.

        The clash you mentioned is very rare. Usually important requests for new
        customers are usually things that new customers will also want, and thus,
        increase our sales. Perhaps we are a bit different, because we only sell
        after long evaluation times, so the feature list isn't the only criterea for
        our sales. We need to be genuinely usefull.
        The only exception to this is consistancy issues. We may find a much better
        way to do something, but it'll be diffrent from what our customers are used
        for. In those cases we'll spend a lot of time and resources for giving them
        a way to retain the behavior they are used to.

        This isn't a promotion for our great customer support, its just another
        prespective on the same issues.
        I guess each company has its own prioritising algorithm :-)
        So either get free software, or a company that takes its customers
        seriously.
      • Gilad Ben-Yossef
        ... Unfortunatly, companies like these are even rares then a working free software based business model... :-) Gilad. -- Gilad Ben-Yossef
        Message 3 of 5 , Aug 15, 2002
        • 0 Attachment
          On Thu, 2002-08-15 at 19:26, Chen Shapira wrote:


          > So either get free software, or a company that takes its customers
          > seriously.

          Unfortunatly, companies like these are even rares then a working free
          software based business model... :-)

          Gilad.

          --
          Gilad Ben-Yossef <gilad@...>
          http://benyossef.com

          "Money talks, bullshit walks and GNU awks."
          -- Shachar "Sun" Shemesh, debt collector for the GNU/Yakuza
        • Oleg Goldshmidt
          ... Recalling my experiences in one (big, multinational) company, here is roughly what the priorities were. - Nothing had higher priority than production
          Message 4 of 5 , Aug 16, 2002
          • 0 Attachment
            Omer Zak <omerz@...> writes:

            > 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
            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 | ogoldshmidt@...
            =================================================================
            "... Of theoretical physics and programming, programming embodied
            the greater intellectual challenge." [E.W.Dijkstra, 1930 - 2002.]
          • Shlomi Fish
            ... 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
            Message 5 of 5 , Aug 16, 2002
            • 0 Attachment
              On 16 Aug 2002, Oleg Goldshmidt wrote:

              > Omer Zak <omerz@...> writes:
              >
              > > 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
              > 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. ;-)
              >

              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

              > --
              > 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:
              > hackers-il-unsubscribe@egroups.com
              >
              >
              >
              > 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?"
            Your message has been successfully submitted and would be delivered to recipients shortly.