21–30 of 35 posts
I think I have knack for seeing and caring about that. I see complexity arising (even if I can't always prevent it, I mean we have to ship too).
Software complexity strikes me as a graph-coverage problem: given a graph of N vertices and M paths (i.e. software components and dependencies), how many vertices and paths do we need to traverse (i.e. understand) in order to make a change to component X? How does that parameter scale with different forms of graph -- linear, n-ary tree, DAG, cyclic (yikes!)?
Or is there a homomorphism between the two problems?
What he studied experimentally with the buttons and threads is know in graph theory as the "Giant component" threshold and is exactly known. https://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93R%C3%A9nyi_...
That's true, but I'm unaware of much work being done on the error bounds for small N (for some concept of small). I started on this during my PhD, but rapidly moved onto other problems that seemed more tractable, and never really returned to it. The results of Bollobás, Erdős, Rényi, and others, are mostly asymptotic. They do, however, seem remarkably good even on graphs of small size (under 10^6 vertices).
When designing something, there are often many choices. If they interact, it quickly becomes intractable. It's tempting to try to keep them in mind, and work out the answer, but with exponentially increasing complexity, your limits are quickly reached (no matter how smart you are). Enhancing your intelligence, e.g. by offloading information onto paper, also has limits.
One solution is the scientific experiment: hold all variables constant, and see the effect of changing just one design choice. Holding them constant means you have made a design choice for that aspect that is almost certainly not optimal.
Ideally, you can do what is suggested in the article - create modules that are largely independent, and experiment within one module in isolation. Because there are fewer variables per module, they are less complex, and it takes fewer experiments to understand how each works.
The deep problem with this is if you don't know what those modules would be - i.e. you don't know which aspects are independent because that's the very thing you're trying to find out! Of course, you can probably have a guess, and certainly use your initial experiments to check those guesses, and maybe with the information gained, improve your guesses.
EDIT a specification is a module, in that it separates out some design choices.
In any software, everything is going to be connected, otherwise there's unreachable code. So the largest cluster is always 100%, so I don't get why his argument about the sudden phase transition is relevant to software?
The author is measuring largest cluster-size vs threads/button. In any software, everything is going to be connected, otherwise there's unreachable code. So the largest cluster is always 100%, so I don't get why his argument about the sudden phase transition is relevant to software?
Uncle Bob was talking about this in his keynote about how Rails is not your application.
http://confreaks.com/videos/759-rubymidwest2011-keynote-arch...
http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch...
Picking up on adrianN's comment[0], when you have a collection of nodes and start connecting them at random, initially they are all disconnected (obviously) and any two that you pick are likely not to have any edges. This in the early stages, your graph is isolated nodes and isolated edges. After a while, by chance, you happen to join an existing edge to a node. That component now has three vertices, and is 50% more…
According to Robert Sedgewick, this particular problem has no known mathematical solution, and the threshold (for a given N) is only obtained through, e.g. a Monte Carlo simulations where you randomly open sites until the grid percolates (akin to the adding of threads). The whole thing is a good application of the union find algorithm.
The threshhold for N > 2 is about 60%. Not sure how that applies to software complexity, but it's interesting to think about.
Thanks, Coursera!
Picking up on adrianN's comment[0], when you have a collection of nodes and start connecting them at random, initially they are all disconnected (obviously) and any two that you pick are likely not to have any edges. This in the early stages, your graph is isolated nodes and isolated edges. After a while, by chance, you happen to join an existing edge to a node. That component now has three vertices, and is 50% more…
For a given first-order sentence s, as n -> infinity, the fraction of models of cardinality n that satisfy s approaches either 0 or 1.
[1] http://researcher.watson.ibm.com/researcher/files/us-fagin/t...
What he doesn't emphasize is the directionality of this phase transition. It's really easy to add one more string, but staring at the resulting button-thread agglomeration it's very difficult to know what string to cut. This is why there is a never ending stream of new projects started to solve the same problems over and over. Their authors covet the opportunity to make progress during the honeymoon period, before th…
I agree completely - once you're on the wrong side of the transition, it is hard to go back
The problem then is when business logic is encapsulated in the mud.
The author is measuring largest cluster-size vs threads/button. In any software, everything is going to be connected, otherwise there's unreachable code. So the largest cluster is always 100%, so I don't get why his argument about the sudden phase transition is relevant to software?
I think the answer to your question is in the missing directions on the threads. The goal of modular software is to have the arrowheads point in the right directions. Uncle Bob was talking about this in his keynote about how Rails is not your application. http://confreaks.com/videos/759-rubymidwest2011-keynote-arch... http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch... https://vimeo.com/21145583