The Quest For Perfect Proportions In Your Software
Filed Under Architecture, Thought Stuff
Without saying, I am impressed how intelligent geniuses such as Leonardo Da Vinci and Beethoven were; however, I am much more impressed how clever they were in applying it to their respective crafts.
One of the most prevalent examples of this is the underlying introduction of the Golden Ratio into art, architecture, and music.
Da Vinci used the golden ratio in a number of his works of art, his most blatant being his Vitruvian Man; however, he also used it in The Annunciation and speculated the Mona Lisa.
Beethoven’s Fifth is found with numerous instances of the golden ratio, as is Mozart’s sonatas. In fact, there is another whole discipline with the Fibonacci series called the Golden String which scrutinizes many violin constructions.
Before any of this – The Parthenon is filled with instances of the golden ratio and other mathematical wonders including optical modifiers.
For almost a year now, I have wanted to write about how software is much like the elegance of music. Both artistic from one perspective yet scientific and mathematical from another. So I continue by pondering the question – what would the Truvian Man or Parthenon look like if it were a MVC application stack?
With a quick introduction to the Golden Ratio maybe we can hypothesize. If the golden ratio equals:
The only positive solution to this quadratic equation is:
OK, now that we have that out of the way, normally we tend to draw a simple 3-tier architecture with 3 equal layers like this:
But what would happen if we apply the golden ratio to this architecture stack? Here are a few permutations:
The one that I hope represents reality the most would be this permutation:
So all of this brings up interesting questions, and lets assume you have your domain model layer completed.
First up, what is the optimal amount of software to support X number of entities?
This question completely depends on the application. Is it a simplistic data in / data out application? Then maybe your ratio of View to Model is closer to 1:1. Does your application have a ton of business logic? Maybe your ratio of View-Controller-Model is closer to 1.6:1.6:1.
Second, how does this change testing?
In the ROI of Testing I speculated at some values at the ROI of unit testing, business logic testing, and automated UI testing. How would that exercise change if your application demanded that you build the very top heavy permutation above (View layer is ~1.6 x bigger)?
In the end, does any of this matter? Being agile means only building the amount of software you need to do the job. If underlying patterns emerged – then neat, but not at all necessary to view the project a success.
500 years from now, I can only hope that someone goes through the hassle of dissecting my code and finding the mathematical brilliance of Beethoven’s Fifth…but in the end it will probably be more like Brittney Spears pop rock…
7 Responses to “The Quest For Perfect Proportions In Your Software”
I would say that your ratio is only that way (Control Layer being 1.6x) because it has to be to support the crazy UI layers that are available to us…
For instance, Windows Forms and ASP.Net… lots of code to get simple UIs up and running with a controller.
But it doesn’t have to be that way…
In the Rails world, they like to take the Model being 1.6x, making things more readable in the UI and the model layer being the brute force of the attack through abstraction. They get away with that due to the Controller and View layer using BCLs. Arrays, ints, strings, etc. No fancy object models like ComboBoxItem.
Just some thoughts…
@Jake –
When I wrote this I was thinking more along the lines that I hoped most applications had a thicker business logic controller layer and kept both the UI and Domain layers fairly anemic.
Your point does resonate with me as I find ASP.NET, JSP, Swing, and WinForms very bloated UI layers. ASP.NET MVC, Spring, and Ruby all do a much better job of bringing this bloat back into proportions.
So thats interesting, sometimes are we forced to deviate away from a “golden ratio” solely based on the framework we are using?
I think that it has a lot to do with it right? The more powerful API you are handed (whether it’s View, Controller, or Model)… the less code that the layer using the API has to write…
It might be the case that due to platform / frameworks, the MVC “weight” is like the classic push pull graph that describes time vs complexity vs flexibility…
If you tug on the UI to do most of the work, you have to route your controllers and models to fit their abstractions… if you have a thick model, you have to morph your controller to fit the UI and the Model abstractions…
What if you’re controller is the thick spot and has a lot of abstractions, does your controller have to grow to fit in the with model and view? It seems so… which leads me to believe that your golden ratio might be the key…
Good thoughts to have on a Monday morning!
There’s no universally-appropriate proportion to the size of architectural layers.
The size of the layers (let alone the relative size, which is merely a side effect) is a reflection of the needs and requirements of a system, including the user experience demands, the complexity of the domain that it serves, and the distribution of the resources that the application addresses, among other concerns.
Consider that the golden ration is often used to address and represent constraints in the physical world. Software isn’t directly accountable to the laws of physics that are in play when constructing the material world.
@Scott –
Can we be for sure?
I know for a fact that you estimate with the Fibonacci numbers, which in turn can be represented by the Golden Spiral.
So in short, your estimation technique actually has an underlying mathematical pattern.
True, I do agree that our focus should be more turned to building solution in an agile fashion, but wouldn’t it be cool if we stumbled across the perfect ratio from which we could then gauge code bloat in frameworks and solutions?
[…] The Quest For Perfect Proportions in Your Software (Max Pool) […]
I was thinking about something similar this past weekend. Instead of terms of software size, I was considering schedule, which is closely correlated. We need an online repository that folks can submit the size of their projects’ layers along with some other details about the project. Objective details could include language break-out within the layers (Java, C, SQL, Ruby), application type, even size of the team, number of persons in each layer or phase of the project (architects, managers, ui designers, coders), etc. Subjective details would be just as interesting. How enjoyable was this project to work on? Do you feel it is larger or smaller than it should be and by how much?