Subject: YA Rule of OS Programming

From: Shlomi Fish <[email-masked]>
Date: Thu, 13 Dec 2001 20:50:18 +0200 (IST)

* The number of items on a project's to-do list always grows or remains
constant.

Regards,

	Shlomi Fish

----------------------------------------------------------------------
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?"

---

From: Oleg Goldshmidt <[email-masked]>
Date: 13 Dec 2001 21:27:17 +0200

> * The number of items on a project's to-do list always grows or remains

This is basic thermodynamics ;-)

-- 
Oleg Goldshmidt | [email-masked] 
"If it ain't broken, it has not got enough features yet."

---

From: Shlomi Fish <[email-masked]>
Date: Thu, 13 Dec 2001 22:37:11 +0200 (IST)

> This is basic thermodynamics ;-)

Naturally it was inspired by the second law of thermodynamics. However,
can you prove that maximal entrophy for a project means the largest number
of items in the project's to-do list?

Also, one must remember that a project is not a closed system.

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/
>
>

---

From: "Nadav Har'El" <[email-masked]>
Date: Fri, 14 Dec 2001 00:09:48 +0200

> of items in the project's to-do list?

If by to-do list you mean list of open bugs and features requested by users,
then you can take a look at bugzilla.mozilla.org for empirical evidence :)
Last time I checked (if I remember correctly), they had 20,000 (!) open
bugs, and the number is constantly increasing.

Anyway, if entropy is number of open bugs, what is temperature - the ugliness
of the code?  and heat energy - human coding energy (i.e., manhours)? If we
do this substitution, do we get (in a reversible coding spree - and remember,
patches can be done reversible!) that

                       Delta S = q/T 

                          means
                                         manhours invested
          Delta (number of open bugs) =  -----------------
                                         ugliness of program

Another alternative is to have heat=number of new users, and temperature=
number of coders. Then

          Delta (number of open bugs) =  number of new users
                                         -------------------
                                         number of coders

But I think I'll leave it to the physicists in the group to formulate
a more consistent theory of bugodynamics :)

-- 
Nadav Har'El                        |    Thursday, Dec 13 2001, 29 Kislev 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Wear short sleeves! Support your right to
http://nadav.harel.org.il           |bare arms!

---

From: Oleg Goldshmidt <[email-masked]>
Date: 19 Dec 2001 00:02:25 -0500

> of items in the project's to-do list?

Shlomi, sorry for not answering promptly enough. I try to defer less
than trivial postings till when I get home, and I don't always recall
that around midnight on the same day...

Anyway, I don't have a proof, and I admire the humorous ingenuity of
Nadav's and leave the field to him (after all, I am a physicist by
training and he is a mathematician, so proofs in thermodynamics are
his domain ;-). I will offer you a simple intuition that motivated me
to mention thermodynamics, which may lead you to agree with me that
the number of bugs / to do items is at least correlated with the usual
notion of entropy adopted for software projects. It may not be a
formal proof, but I hope you will agree that it is not totally absurd.

Recall that entropy is k*log(W), where k is the Boltzmann constant,
and W is the probability to find a system in a particular
configuration. W is related to the number of states / complexity of
the system - the more possible states there are the higher the
entropy. To give you a trivial example from real thermodynamics: you
probably remember from your high school physics (let alone the
Technion - nudge, wink) that if you take a volume of gas and decrease
the volume (e.g. with a piston), the entropy will decrease. This is
because there are fewer states (fewer spatial positions) available for
the gas molecules. Left alone, the gas will push the piston outwards,
increasing the volume, the number of available positions (states), and
entropy.

Now, most projects tend to grow, become more complicated, and acquire
more states, and effectively the maintainer will have less and less
information about the configuration of the project with time. This
means that the natural tendency of an unmanaged project is an increase
of the project's entropy. That there will be more bugs and to-do items
stands to reason to anyone who ever maintained anything non-trivial. I
think that complexity/information line of thought makes it intuitive
that there must be a correlation between entropy and the length of the
bug/to-do list.

> Also, one must remember that a project is not a closed system.

This is an excellent remark with ramifications so profound they may
seem obvious. Btw, I hope by "not closed" you did not mean that others
can participate in the development of an OS project? That would not be
consistent with the notion of entropy given above, as more developers
will increase the number of available states. To get a non-closed
system we need a piston that will bring some order into the mess -
project management (at least technical management, not
suit-management).

Given the above, it should be clear that successful project management
should strive to minimize entropy (and hence the to-do list). One
wants to push the piston in. Software-wise, this means that one needs
to design and modify the software in such a way that the number of
available states / complexity / entropy will decrease. You will do
better than myself from this point formulating corollaries such as
"featuritis is bad", "spagetti code is bad", "haphazard patches that
don't fit into the overall design are bad", "modularity is good",
"well-thought-through design is good", "some style policies are
helpful", "adding more people will probably hurt" (that's the famous
mythical man-month for those who have read - or heard of - the
classical text), etc, etc.

Another corollary is that for successful maintenance you need
information (also known as negentropy). Did anyone scream
"DOCUMENTATION" at this point?

Of all of the above I'd say that the idea that applying a quick,
haphazard kludge as a bug fix "for now" is likely to increase entropy,
and thus is hazardous for your to-dolist, appeals to me most.
 
Finally, the above is tongue-in-cheek, of course. I will leave it to 
each reader to decide for himself/herself if it is stupid. Flames will
go to my system's thermostat marked /dev/null.

-- 
Oleg Goldshmidt | [email-masked] 
If it aint't broken it hasn't got enough features yet.