(Originally from OpenSourceCommunism)
[This page was originally on OnceAndOnlyOnce
, then moved to OpenSourceCommunism
. The content discussing whether or not OpenSource
is communism was left there. OAOO is not a practice explicitly discussed in OpenSource
. There is no obvious connection.]
[The following text occurred in the middle of the OpenSourceCommunism
discussion but starts by explaining the confusion motivating this refactoring before delving back into OAOO.]
? There are at least two graphical open source web browsers, three word processors, and four (count 'em, four) open source POSIX operating systems. Certainly, open source software does not follow the Soviet-style central planning model.
And dozens of open source text editors.
Um... OpenBSD, FreeBSD, Linux, ... umm... and what else? NetBSD, Darwin, perhaps GnuHurd if it's ever finished.
Who's complaining about having adequate consumer choice? I thought that having consumer choice was preferred. But this is off topic - it (OnceAndOnlyOnce) wasn't referring to Open Source. This tangent was sparked by two quotes from AurelianoCalvo, from a discussion that has erroneously been placed on this page [i.e. OpenSourceCommunism]. The first quote is "I believe that Communism advocates OnceAndOnlyOnce and Capitalism doesn't". The second quote is "What really bothers me is the clear paralellism between OnceAndOnlyOnce and CorporateMonopoly?". Aureliano thus suggests that monopolies are justified by or are an example of OncAndOnlyOnce. In neither quote, nor in the discussion itself, does he mention Open Source, or make any comparisons between Open Source and Communism. Anyway, OnceAndOnlyOnce is a design principle, not an economic principle. OnceAndOnlyOnce is great for coding and design, but bears little (if any) weight in justifying monopolies, nor has empirical evidence been brought forth to justify it as an economic goal or principle. Anyway, though monopolies are great for corporations, it's corporate competition that benefits consumers - and having consumer choice is preferred by everyone, including economists.
That is nonsense. Ask yourself if having only one company which distributes Linux would be ok. Or if LinusTorvalds
could maintain Linux, BSD, NT and OS/390. OnceAndOnlyOnce
is for LinusTorvalds
to maintain only Linux. That doesn't mean only one company should distribute Linux. See MoreIsBetter
OAOO and the economy.
I believe that communism advocates OnceAndOnlyOnce
and capitalism doesn't. In communism, a single entity (the state) provides for all, while in capitalism, many different entities (enterprises) build the same (or almost the same) product. If we apply OAOO to economy, the way to go is: "Communism and Monopolies". This really bothers me.
Software and communist economies are built by programmers and dictators (respectively). Free-market economies grow organically. When code gains self-interest, and can grow and correct itself, we won't need to do OAOO any more. If people lose their self-interest, and lose their ability to organize themselves, we will have to go back to OAOO in the economy.
Perhaps an explanation would help more than the blunt statement:
IMHO: Communism is not OAOO; it goes too far and eliminates correct establishment of a "once" for each useful case in favour of a less correct option supplied by the state for all cases. It stifles "refactoring" (innovation) that would support OAOO in other circumstances by mandating a generalized static solution. Capitalist duplication of effort/products/etc. could be considered a refactoring or a solving of a different problem - the exact price/quality/functionality point a consumer is looking for. If the combination (of price, quality and functionality) is superior in every way (better quality and/or less expensive with at least as much functionality), then it supersedes previous instances, which better approximates OAOO since the earlier version will ultimately disappear.
Maybe, you are looking at defective communism implementations. I don't see why communism encourages not to refactor. But I see why Stalinism does. What really bothers me is the clear paralellism between OnceAndOnlyOnce and CorporateMonopoly?
But now it is possible to adapt the products to the needs. "Soviet-style central planning model" is just a defective communism implementation. Maybe, eventually only one of each will exist
Wow, what a fantastic question and line of thought! Here's an idea for an answer. OAOO is concerned with efficiently directing resources to serve the purpose of the person or party who is paying for it. Capitalism is an economy based on negotiation. A free-market economy is not planned for the good of all by some top-level authority who ensures that everything is done efficiently. It's a massive, negotiated compromise between everyone's attempts to do the same, within their (overlapping) spheres of influence. In a free market, you don't need permission to open up a shop; you don't need to justify it on the basis of public benefit or non-duplication of effort. You are allowed to negotiate your way into the system. It's only a fortuitous side-effect that this sort of negotiation actually results in vastly greater efficiency than centrally planned economies, due to the way information percolates through the system via prices.
But that's not quite right. The reason for OAOO is not efficiency, as indeed code is so cheap that saving memory space doesn't matter. Ok, second attempt. The reason for OAOO is maintainability: the ability to change the software while still ensuring that it's dependable. OAOO is one way to make software resistant to uncertainties like ever-changing requirements. In non-software things, though, you become resistant to uncertainty - sometimes even more able to exploit the unknown when you find it - through redundancy. A perfectly efficient system is a perfectly frail system: remove any one element and everything goes crashing down. See TomDeMarco
's book Slack.
In software and in scientific theories, though, we strive for exactly that kind of frailness. In those areas, it actually makes things more robust. And indeed, not only in software, but in the academic economy, OAOO is strongly favored. Outside of communism, the only other area where OAOO is favored is large organizations, like the military, big government, and big corporations. Unlike software and academia, these deal with a physical economy, and they are renowned for both their inefficiency and
their slowness to respond to unpredictable changes.
Wow, interesting. Thanks for bringing this up, Aureliano!
- Why is it that O
nceAndOnlyOnce is acceptable in development?
''Because it discourages redundant code (and thus bloated software). Having less redundant code would result in having fewer bugs, since you would only have to make sure that that one instance is correct - you don't have to track down and debug all its other instances. It also discourages ReinventingTheWheel
. Refer to OnceAndOnlyOnce
for a better and more thorough explanation. -- CarlosNsRodrigues
We ask for OAOO so that we can more easily reason about change to our programs. OAOO is a simpler and more actionable advice than asking for useful abstraction. Still, OAOO and the other extreme practices yield useful abstraction and abstraction aids reason in programming much like it does in mathematics. It is possible that some mathematical fantasy inspired communist theory, but communism's central planning and extreme programming's self organization couldn't be more diametrically opposed. -- WardCunningham
Curiosly, unlike OAOO, self-organization is
a central concept in both ExtremeProgramming
. -- JasonNocks
Uh, is it really necessary to point out that governing or managing human beings and governing or managing software are two very different things with very different success criteria? Like, in any discussion of governing people, individual liberty is an essential part of the discussion. Even the most ruthless dictators routinely at least pay lip service to the idea of freedom, either "explaining" how the present tyrany is required to get the nation through these temporary problems, how the freedom of some must be restricted for the benefit of all, that "real freedom" is the right to live free of fear of those dangerous forces that oppose the state, etc etc. But, despite all the science fiction stories about robots and computers who are self-aware and intelligent, in real life software doesn't have any desires or motives or feelings. It doesn't care if it is "free". A government that allows every individual to do whatever he wants, limited only by respect for similar rights of others, is viewed by many as the ideal. A computer system that allowed every module to do whatever it wanted, even if somehow achievable (as in, how would the modules "decide" what they wanted to do?) would surely be useless.
Or if we don't care about ideas like freedom and justice and only about economic efficiency: Still, capitalism works because it gives people the opportunity to develop competing solutions to problems, and then permits the market - that is, the interested population - to decide which solution is best. Communism and socialism fail because they give one small group the power to decide on a solution and impose it on everyone. If you could somehow guarantee that the state planners would always be the smartest, most capable people in the country, so that their ideas decisions would ALWAYS be better than the ideas and decisions that anyone else could come up with, then I suppose communism would be more efficient than capitalism. But with a software project, the modules don't come up with ideas on how to improve themselves or implement other modules. The developers - people - have to create the modules. It's often said that the problem with communism is that it treats people like machines. We shouldn't treat people like machines, and we certainly shouldn't treat machines like people.
Capitalism somewhat is related to natural selection
. Darwin even cites capitalism theory as helping to spark his insights. But natural selection violates OnceAndOnlyOnce
up the wazoo. DNA is copied gazillion times. Even though there is sexual recombination, large chunks of genes are pretty much exact copies. Thus, natural selection did not "evolve out" duplication.
Even within a given DNA specimen, sequences are often duplicated many times, often with some mutations. If removal of duplication is an important factor, then why didn't it somehow evolve out of DNA? I suspect its because DeltaIsolation
is more complicated to keep strait than duplication-with-modification. (Although there is some research in gene expression modifiers that may involve DeltaIsolation
Removal of duplication is a crucial factor in successful human development and maintenance of code. In genetic systems -- where code is maintained via natural selection rather than human engineering -- duplication may actually be favoured, as it gives an organism resiliency against genetic damage.
Similar issues arise in code. If you duplicate, you can alter one of the copies, such as for customization, without fear of breaking the other. Fixing shared code has a wider risk range.
Perhaps. But if you've created a universal computational artifact -- say, a data structure like a linked list -- it makes little sense to duplicate its code everywhere. A linked list is a linked list. It's unlikely to ever change, especially if you've made it sufficiently abstract to handle all foreseeable cases. On the other hand, if you discover two sets of business rules -- perhaps defined by separate departments -- demonstrate some coincidental similarity, there may be risk-avoidance value in duplicating the code that implements it. However, it's almost always easier to extract special cases as they arise, rather than endure the tedium of (and risk new bugs in) fixing the same bug or adding enhancements to the same code spread throughout a large project.
A linked list that is "sufficiently abstract to handle all foreseeable cases" will turn into a database.
Huh? I write DBMSes, among other things. Linked lists are common, but I have yet to see a reason to use another DBMS to implement a linked list in my DBMS. The phrase "AbstractionInversion" comes to mind, as does "abstraction perversion."
- You said "handle all foreseeable cases". Quick (indexed) searching is one such case. Resorting/reordering is another. Along with adding more attributes to each node, multi-user concurrency. Etc. Etc. Etc. Perhaps handling "all" does indeed take an AbstractionInversion. Genericness is not always easy to achieve to the maximum (if there is such a thing) without a big engine.
- In retrospect, I should have written "handle all forseeable cases for a linked list" A more complex data structure would no longer be a linked list per se. I assumed (perhaps mistakenly) that would be obvious.
- But its kind of an arbitrary border. When changes come along, they don't care if they force a DiscontinuitySpike on the design or jump beyond a name or definition. Changes are blind and uncaring. The need to do new things to existing data structures is common in my experience. --top
- True, but I think my previous statement still applies: It's almost always easier to extract special cases as they arise, rather than endure the tedium of (and risk new bugs in) fixing the same bug or adding enhancements to duplicated code spread throughout a large project. I find OO inheritance especially of value here, because special cases can often be extracted into subclasses, which still allows changes that affect all functionality -- in the original and the special exceptions -- to be made OnceAndOnlyOnce in the base class. I.e., rather than alter every instance of a data structure, simply create a subclass to handle those places where a change is needed. Of course, there are occasional changes that break everything (the programming equivalent of "thanks for building me the new house -- now, could you raise the roof an inch and make all the windows two inches wider") but there is no approach that avoids a re-write in such cases.
But in general software design can be compared to investment management: you make your best guess about the likely patterns of future change and your design reflects those best guesses.
With that, I agree wholeheartedly.
Guys, OAOO is a practice for making *your* project better, and your life easier. It does not address the interactions between your project and other projects - you might have a server handling requests - should you eliminate all but one variety of client? All but one instance of client? No, obviously, but you might within your code
remove duplication of client object code so that all clients are treated the same.