This is absolutely false. This talk: https://www.youtube.com/watch?v=3OgbQOsW61Y does an excellent job of introducing some basic theory on good design, with solid (heh) justification for each principle.
You can see plenty of companies that follow those principles and still end up in bad places.
Theory is like number theory. You need axioms and theorems. Just because you assign acronyms and big words to things doesn't make it a "theory". You need proof or empirical justification.
Solid is like scrum, someone made it up. It was pulled out of someone's ass. Doesn't mean it's bad, but it's not categorically correct, it's more of someone's opinion.
Something that is categorically correct is complexity theory for algorithms. You can definitively say Algorithm A is better than algorithm B from a performance perspective. But for program design and organization? Is one design better than another? How Solid is one design vs. another design? Can you concretely even define Solid in formal terms? No.
I say again there is no theory on software code organization. None.
Anything that's called "Design" usually means there's no "theory" around it. It's all ad-hoc gut feelings and made up. Things like UI or art typically have a lot of "design" associated with it.
Usually a "theory" is a very concrete thing. You don't "design" the shortest distance between two points. That's more of a calculation. A calculation is available because we have a formal theory called geometry.
We can calculate which algorithm is better because we have a formal theory around algorithm speed and memory.
But program organization? No. No theory. Just rules of thumbs and made up acronyms and big words masquerading as theory. We don't truly even have a formal definition of "good program design" or "technical debt" It's these nebulous terms and the culture shifts and changes with new fads all the time.
OOP used to be big with OOP design patterns as a big thing. Now OOP is on it's way out... Do you see that with geometry? Can the theory of geometry be a fad? You may not know it, but even SOLID is more religion than it is formal theory.
The closest thing to a formal theory of program organization I've seen is within functional programming and category theory. To get a formal theory for program organization we have to come of with formal definitions. What is good design? What is modularity? How do we compare the modularity of one program to another? None of these things have been defined yet but it looks like category theory and functional programming has sort of the primitives to build upon to make these concepts concrete. We're still far away from something formal but if we ever develop something along these lines it will likely arise from Functional programming or category theory.
He calls it "program design by calculation" but it's really just program design using algebras. He can't prove why it's better because, again, lack of theory but it looks like this approach is generally the right direction.
Oh wow, thank you for this write up, this is great! I think you've convinced me a little bit, and I'm super down to get into this discussion.
If I'm understanding all this correctly (and I was never all that good at this level of math), what you're saying is that we don't have a way to, essentially, calculate the "goodness" of code using math. Or, in a practical sense, your linter can't tell you how much tech debt you've got.
And - yeah, I think you've convinced me that we don't have that. Not as a complete theory like geometry, anyway.
...but! I do think we've got some solid steps in that direction. There's a lot of things we can calculate - LoC, symbol counts, "cyclomatic complexity" - so then as I see it, the gap is connecting those metrics to "goodness" in a solid enough way that it'd cross the threshold into "formal theory". Which might not be possible, if "goodness" itself can't be nailed down.
One of the big reasons I like the talk I linked above is that I think it takes a solid (heh) step towards making that connection. You can use the techniques within to measure "how much change was used to accomplish something" (although there's issues with that measurement, from "what's the unit?" to "how do you normalize that against, say, the size of the something?" and "that's how much was used, but could less have been used?").
I'd then propose that "goodness" is something like a weighted sum of a few metrics, one of which is that "how much change was used", and further, that there are measurable things that can tell us something about how much change might be needed - although to your point, none of it a degree of completeness that'd constitute a theory.
I guess, at the end of the day - I think we do have enough to propose some basic theories about program "goodness". SOLID could be one such theory, if it were rendered into much more formalized language.
>...but! I do think we've got some solid steps in that direction. There's a lot of things we can calculate - LoC, symbol counts, "cyclomatic complexity" - so then as I see it, the gap is connecting those metrics to "goodness" in a solid enough way that it'd cross the threshold into "formal theory". Which might not be possible, if "goodness" itself can't be nailed down.
Lines of code? So less lines of code is better than more lines of code? So If I fit my program into one line it's better? That's not a good metric.
But then you say add it up with symbol counts and cyclomatic complexity and the average of the three should counterweight any inaccuracies that stem from each individual metric.... but does any of these metrics have anything to do with good design as our intuition defines it? I would say No.
The problem is our intuition of good design encompasses more than what all these things measure. The core principle that most people agree on that is fundamental to good design in programming is modularity. How do I design code so that any modification to the application is as much as possible more a reconfiguration of existing primitives rather then a rewrite or re-architecture? I want to design my coding primitives to be legos that fit together perfectly and any change is just reconfiguring those legos. However, in bad designs I find that my primitives don't act like legos. A new feature may often necessitate rebuilding and refactoring previous primitives and changing the way things work in order to get that feature in. Essentially new lego pieces are needed and editing lego pieces and changing the way lego pieces connect points to mistakes made in the initial "bad" design.
Note that None of the above has anything to do with cyclomatic complexity or symbol counts. You can have highly modular code with high cyclomatic complexity, you can have highly modular code with many LOC, and you can have highly modular code with high symbol counts. That's just one problem with your proposal.
This is the other problem:
Your "metric" is just a "metric". Theories don't deal with metrics as metrics are statistical measures... like how an average that hides the individual values. This approach is less "theory" and more "scientific" I would say. It has some validity but it treats the system as more of a black box and uses a very blurry metric to essentially guess how good a program is. But this is no theory.
>I guess, at the end of the day - I think we do have enough to propose some basic theories about program "goodness". SOLID could be one such theory, if it were rendered into much more formalized language.
It can't. SOLID is like color theory. It's made up. You know why color theory is bullshit right? It states that there are three primary colors, red, blue and yellow and all colors stem from those three primary colors when in reality color is a wavelength and our eyes only have cones for RGB. Yet people from both within art and outside of art fall for this theory because it presents itself in a beautiful way with the color wheel, secondary colors and tertiary colors. I mean somebody just made this shit up and it became convention in the field of art. Believe it or not much of computer programming outside of academia is full of color theory-esq bullshit. Take Solid:
The whole acronym SOLID is just as gimmicky. Someone chose certain words and decided to order those words so it spells "SOLID"... I mean that's more marketing then an actual attempt at a formal theory. It's just staring you in the face. It's not speaking to some foundational aspect of software design it's something someone pulled out of their ass. Like color theory it actually somewhat works, but also like color theory there are aspects of it that won't work and are utter bullshit.
You've probably been a staunch believer of SOLID for a while now. Impossible for people to change a long held view from logic alone. Such change takes time. I'm not saying SOLID doesn't work, it could be quite practical. I'm saying SOLID isn't anywhere near a formal theory nor does it have any chance of becoming an actual theory, it's like color theory... just rules of thumb for an artist and like color theory it's very very incomplete and likely not accurate to what's really going on with a "bad design".
The sad part here is that there's no alternative to turn to. Since there is no formal theory, bullshit stuff like SOLID or GOF Design patterns are much more likely to exist because we have no solid foundation to compare these things to.
Woah woah woah - I'm not saying that LoC directly measures quality. I'm only saying that it's a concrete, measurable thing. It can then be used as an input to any theory of code quality, not as a direct measure of code quality.
"But then you say add it up with symbol counts and cyclomatic complexity and the average of the three should counterweight any inaccuracies that stem from each individual metric.... but does any of these metrics have anything to do with good design as our intuition defines it? I would say No."
I understood your objective here. But my counter to it is much longer than the first paragraph. You'll have to read the whole thing carefully. There are several reasons why your approach doesn't qualify as theory and why it has problems. It's more of a statistical or analytical average then it is a formal theory.
Hmm. It sounded to me like you were saying a straight sum, or maybe a weighted sum. That’s not what I’m getting at.
Subjectively, Rubocop pushing me to have smaller everything by LoC made my code better. As has reducing function cardinality.
Both of those are as straightforward a metric as “angle of incidence” or “length of a side”; and I can’t help but imagine there’s theorems that can be made from them akin to the Pythagorean. Although whether it’s possible to go from there to “code quality “ - yeah, might not be possible.
> Hmm. It sounded to me like you were saying a straight sum, or maybe a weighted sum. That’s not what I’m getting at.
Doesn't matter how you aggregate these metrics. In statistics you have all kinds of arbitrary aggregations that attempt to form a blurry "summary" of what's going on. These "aggregations" like the mean, median, mode, standard deviation, weighted average... etc... are made up as well. It's arbitrary and essentially just summaries of what's going on. You're just proposing another aggregation and obviously a blurry one too.
You're not picking out the "angle of incidence" or the "length of a side". More like out of 1000 triangles you're picking out all the sides and averaging them to get some summary of the length of sides of all triangles. You can see how this statistical metric is different from say euclidean geometry right?
A concrete formal theory involves definitions. What is the formal definition of a module? What are the formal rules for how modules compose? Can we put a formal algebra together that allows us to implement these rules and for theorems around these things? We want a formal theory of program organization that is akin to euclidean geometry, not some data sciencey aggregation.
> It can then be used as an input to any theory of code quality, not as a direct measure of code quality.
It can be part of an explanatory model of code quality once you have a concrete metric for code quality. That is, if you can measure code quality independently of features of design, then youc an build a theory of design using measurable features of design/implementation like LoC that explains how thost features determine quality.
But otherwise your "theory" is not a predictive/empirical theory and something more like various schools of literary theory.
This is absolutely false. This talk: https://www.youtube.com/watch?v=3OgbQOsW61Y does an excellent job of introducing some basic theory on good design, with solid (heh) justification for each principle.