{"id":186,"date":"2013-02-25T15:14:12","date_gmt":"2013-02-25T14:14:12","guid":{"rendered":"http:\/\/serverdude.dk\/?p=186"},"modified":"2013-02-25T15:15:10","modified_gmt":"2013-02-25T14:15:10","slug":"big-ball-of-mud-with-physics","status":"publish","type":"post","link":"https:\/\/serverdude.dk\/?p=186","title":{"rendered":"Big Ball of Mud with physics"},"content":{"rendered":"

\nBeing a fan of Foote<\/a> and Yoder’s Big Ball of Mud paper<\/a>. Well, fan in the sense that I think it is a correct observation of most software developed, yet not liking that fact.<\/p>\n

\nSo I have been pondering on this \u00e2\u20ac\u201c donning my amateur physicists hat I have contemplated some of the issues.<\/p>\n

Tournaround<\/h2>\n

\nLet’s say that we have a team of developers pushing the project forward. Let’s call them Sisyphus<\/a>. They have a development velocity, v. The ball of mud has a radius, r, which is comparable to the number of features in the product. The angular veloticy, \u00cf\u2030, is proportional to the frequency of revolution, let’s denote this as the version number.<\/p>\n

\n\u00cf\u2030 = v\/r<\/p>\n

\nThat is, as the radius grows, then \u00e2\u20ac\u201c given the velocity is constant \u00e2\u20ac\u201c the angular velocity reduces, which in turn means that the versions will be harder to crank out.<\/p>\n

Work<\/h2>\n

\nWork, W, is force, F, times the distance, s, which in turn is the velocity times the time passed.
\nThe force is mass times acceleration, and the mass is density, \u00cf\u0081, times the volume, V.<\/p>\n

\nW = F \u00ce\u201ds
\n\u00ce\u201ds = v t
\nF = m a = \u00cf\u0081V a<\/p>\n

The volume of a sphere is 4\u00cf\u20ac r3<\/sup>\/3<\/p>\n

\"ball-work\"<\/p>\n

\nThus the work is proportional to the radius of the sphere cubed.<\/p>\n

The interpretation<\/h3>\n

If something requires twice the number of features, then the work required will be 23<\/sup> = 8 times greater or run at 1\/8 the velocity.<\/p>\n

\nIf \u00e2\u20ac\u201c on the other hand \u00e2\u20ac\u201c this could be done in two disjoint balls of mud, it would only require twice the amount of work.<\/p>\n

\nMore generally, we could probably divide the features of the big ball of mud into two smaller balls having different radii, R and r.<\/p>\n

\nThe Volume of the original ball with radius R+r will be:<\/p>\n

\n\"ball-volume\"<\/p>\n

\nWith the volumes of each of the lesser balls as:<\/p>\n

\n\"balls-volume\"<\/p>\n

\nEffectively being \"ball-bigger\" smaller than the larger ball. We are actually saving more than 6 times the volume of the smallest ball.<\/p>\n

\n\"ball-excess\"<\/p>\n

\nIf we split the big ball into 80% and 20%<\/a> \u00e2\u20ac\u201c which is likely, then the combined volumes of those two smaller balls would save
\n \"ball-save\"
\n48% of the original volume.<\/p>\n

\nIf volume is comparable to complexity, then we will save complexity and development effort in keeping the balls as small as possible. Nothing new there.<\/p>\n

\"biball\"<\/p>\n

\nThis is just another argument for low coupling and high cohesion. But it is also a reminder that we must look at our code from a different perspective from time to time. Are classes adhering to the Single Responsibility Principle<\/a>? <\/p>\n

Disjoint Communication<\/h2>\n

\nIf the Big Ball of Mud is split into several smaller balls, they would probably need to communicate. This would have been some of the intrinsic complexity we shaved off. <\/p>\n

\nLet us try to add it in the most stupid form possibly: A complete graph<\/a> in which each and every ball will know and communicate with each and every other ball.<\/p>\n

Renaming the radii having R as the radius of the original Bug Ball of mud, and divide it into n = R\/r balls of approximately the same diameter, r. Then taking the added complexity into account we get n(n-1)\/2 additional entanglement. Leaving us with:<\/p>\n

\n\"ball-entangled\"<\/p>\n

Which about the original volume divided by 2n.<\/p>\n

\nAs a complete graph is just inverting the big ball of mud, there is a minimum of n-1 connections for a completely connected graph. That is, the refactored ball of mud could \u00e2\u20ac\u201c at best \u00e2\u20ac\u201c save an additional factor of n.<\/p>\n

Different distributions<\/h3>\n

What if the balls cannot be split using an equal distribution? Perhaps we should contemplate a more natural distribution such as a power law.<\/p>\n

Doubling down<\/h4>\n

Dividing the original radius into n different sizes each half the length of the previous, but with twice as many balls. <\/p>\n

\nDividing into n=4 different sizes we get:<\/p>\n

1\/4 + 2\/8 + 4\/16 + 8\/32 = 4\/4 = 1<\/p>\n

\nThat is, we get 24<\/sup>-1 = 15 balls, the biggest of radius R\/4.<\/p>\n

\nThe general formula for volume per size is now:<\/p>\n

V(c,r) = 4\/3 \u00cf\u20ac c r3<\/sup><\/p>\n

\nWhere c is the number of balls with the radius, r. <\/p>\n

As the communication is no longer of equal size, we have to do some more work. The rectangle spanned by the two communicating parties radii seems a fitting proporsition.<\/p>\n

We end up with the following formula for added complexity due to full communication needs:<\/p>\n

\"ball-comm-sum\"<\/p>\n

As R is a factor of all radii, we see that Vcomm is an area in R2, whereas the volume, V, is a volume in R3. This means that we shouldn’t be allowed to add them, but as we’re not concerned with this type of detail we add them anyway but notice that the effect is dependent upon the initial radius, R.<\/p>\n

Using the relative complexity as the yardstick, we can plot the effect of R and n. Remembering that we’re getting 3 balls for n=2, 7 balls for n=3, and 15 balls for n=4.<\/p>\n

From the graph it looks as though the initial radius doesn’t matter as much.<\/p>\n

Furthermore, it seems that the best value would be to split into 2 or 3 different sized smaller balls. Going beyond seems futile as the gain from splitting the largest ball left would probably be bigger \u00e2\u20ac\u201c given that the initial radius doesn’t matter as much.<\/p>\n

Without full communication needs the relative complexity would be even lower.
\n\"doubledown\"<\/p>\n

Conclusion<\/h2>\n

While it is human nature to hoard development into a single monolithic big ball of mud. It does pay off to break down the monolith to a certain degree. Whether for sanity, savings, or speed.<\/p>\n

\nThe notion of equal distribution \u00e2\u20ac\u201c which corresponds to disection into primitive obsession \u00e2\u20ac\u201c is luckily reverted by the doubling down distribution. Which is likely to be a more natural division of elements.<\/p>\n

It does seem counterintuitive to work at a constant pace and still grind to a halt. Yet this seems to be a logical conclusion of the above calculations. If not to a complete standstill, then at least turning so slowly that it seems like a complete stop.<\/p>\n

I didn’t consider friction in the above calculations. Friction would impact on the complete forces, and thus on the work \u00e2\u20ac\u201c but not in a positive way.<\/p>\n

The question now is: Will a Big Ball of Mud collapse under its own weight if not cared for?<\/p>\n","protected":false},"excerpt":{"rendered":"

Being a fan of Foote and Yoder’s Big Ball of Mud paper. Well, fan in the sense that I think it is a correct observation of most software developed, yet not liking that fact. So I have been pondering on this \u00e2\u20ac\u201c donning my amateur physicists hat I have contemplated some of the issues. Tournaround […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-186","post","type-post","status-publish","format-standard","hentry","category-programming"],"_links":{"self":[{"href":"https:\/\/serverdude.dk\/index.php?rest_route=\/wp\/v2\/posts\/186","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/serverdude.dk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/serverdude.dk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/serverdude.dk\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/serverdude.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=186"}],"version-history":[{"count":15,"href":"https:\/\/serverdude.dk\/index.php?rest_route=\/wp\/v2\/posts\/186\/revisions"}],"predecessor-version":[{"id":211,"href":"https:\/\/serverdude.dk\/index.php?rest_route=\/wp\/v2\/posts\/186\/revisions\/211"}],"wp:attachment":[{"href":"https:\/\/serverdude.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/serverdude.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=186"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/serverdude.dk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}