-Max

-Max

Yes, it is fundamentally an empirical science. But for me to say that something is a law, I personally like to have a philosophical basis for it–that is, I like to know why it’s true, not just that it is.

I did actually arrive at all of the laws empirically, and in fact in my original drafts for my book, I called all of these “rules” instead of “laws”, because I couldn’t prove them sufficiently for me. The final test of any engineering law is “Does it work?”, but I personally just like to have a “why” before I say that something is really a law.

I think your economic derivation is very interesting! I suspect many of these laws could be derived in various ways. And of course, as I said, in fact I actually observed them first and derived them second.

I can’t really say much about AllPeers. Did it become unmaintainably expensive because of the code design? I don’t know. I’d guess that operating costs would be high in any case, but I really have no idea. There are definitely factors outside of design that can make a project fail, but that’s outside of the area of these laws. That’d be more of a management issue, and less a technical issue.

-Max

Or maybe I’ve just been overexposed to rigorous mathematical texts that really don’t leave any room for doubts (once you actually manage to understand the 3 page proofs for some seemingly simple theorem, that builds on at least 4 previously proven theorems…), and I should give your laws a little more breathing space. I mean, empirical science (as opposed to pure mathematics) rarely works with axiomatic laws and logical derivations, but it’s laws are “based on a sufficiently large number of empirical observations that it [are] taken as fully verified”. Which is maybe why I’m a bit confused. You use axioms and logical derivation as in pure math (but because it’s more of an empirical science, they lack rigorous proofs), but on the other hand, for it to be an empirical science, it lacks concrete data. I confess, I’ve used Wikipedia’s article on science to put my thoughts into words and (even up to the point of citing it), but it seems to nicely express the source of my doubts.

If you feel that I’m generating too much stop energy, feel free to ignore me I mean, the resulting law is very interesting, just the process you used to arive at it seems a bit weird. Besides, you could arrive at the last law using other, more empirically proven methods (and methods that have been studied much more deeply), such as some sort of “economics”:

1. If a program satisfies demand, it makes a benefits (or profit, but it doesn’t have to be $$)
2. If a program stops satisfying a demand, it makes less benefit.
3. Less benefits are bad (all of these laws are axiomatic)
4. To keep a program making benefits, it needs to keep satisfy a demand.
5. To keep satisfying a demand, it has to be developed, which has an associated cost (this could be disputed, there are other, more sinister ways to force users to be satisfied by a particular program than making the program better)
6. If we develop it too much, the cost of development will be higher than the benefits (this is bad)
7. We need to develop the program in such a way that it still satisfies a demand, but the cost doesn’t overweight the benefits
8. Ergo, the less we have to develop while still keeping stable benefits, the better.

Now we copuld go into a lengthy analysis of the ways in which a program stops making benefits (defects, changes in the environment, change in demand), or say that there is a correlation between the the design of a program and it’s development costs… but it just comes down to cost benefit analysis (and also explains the recent downfall of AllPeers, which has been stopped because a lack of funding. Would a better “code design” of the AllPeers software made it still exist today?)

-Max

This almost sounds like a definition of “modularity”.