5 ms·

There's no theory on good design. You organize your code one way versus another way nobody can really point to any mathematical proof or empirical evidence for

There's no theory on good design. You organize your code one way versus another way nobody can really point to any mathematical proof or empirical evidence for anything. It's just one baseless arrangement vs. another. This is why, often, when you refactor code it doesn't make it better. You don't fully know if it's better. It's just another way. So even when you do this refactor stuff often you find yourself in the SAME situation even if you didn't touch it. Think about it. You follow best practices, you try to write code as beautifully as possible. That doesn't actually prevent a new feature from having you to gut a huge portion of your code to accommodate it. But developers don't realize this. They think the extra time spent refactoring puts them in a better place then before. But really they just can't see the counter factual. Did it really? I've been in places that emphasize on good code quality and put lots of good practices in place but they end up with "tech debt" anyway. Then when clean up day comes they blame it on bad practices and shortcuts but they're blind to the fact that the they were one of the most rigorous companies in terms of code quality.

RangerScience 3y ago
> There's no theory on good design. This is absolutely false. This talk: https://www.youtube.com/watch?v=3OgbQOsW61Y 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.
- corethree 3y ago
  That's not theory. It's just a bunch of opinions. 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.
  - RangerScience 3y ago
    Alright, what’s your criteria for a “theory”? Similarly, what’s your criteria for “program design”? I want to have a better idea of the goal posts that you’re setting.
    - corethree 3y ago
      formal theory is the full term. https://www.wikiwand.com/en/Formal_theory https://www.wikiwand.com/en/Formal_theory The first three definitions fit. 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. Check this resource if you're interested: https://www4.di.uminho.pt/~jno/ps/pdbc.pdf https://www4.di.uminho.pt/~jno/ps/pdbc.pdf 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.
sz4kerto 3y ago
Refactoring is generally not about the code style, or changing the design for its own sake. Refactoring happens because the model of the world that the software works with has changed since the software has been implemented. Maybe the way users and roles are represented was kinda OK 5 years ago, but the world (== business environment, understanding, requirements) has changed since. So the code that has been OK 5 years ago is painfully mismatched with the present. That's when refactoring is needed. Also. Tech debt is usually (not always) the marginal cost of the next feature. If new features cost X, and engineers are convinced that features could cost much less if the software was organised differently, then it might be useful to calculate the cost of a refactor.
- corethree 3y ago
  >Refactoring happens because the model of the world that the software works with has changed since the software has been implemented. Maybe the way users and roles are represented was kinda OK 5 years ago, but the world (== business environment, understanding, requirements) has changed since. So the code that has been OK 5 years ago is painfully mismatched with the present. Totally agreed. This is a practical reason for it. But much of refactoring doesn't happen because of this. The article says you should refactor all the time for "better" code. It's not talking about your use case where you have to update dependencies, security features and things like that.

RangerScience 3y ago

> There's no theory on good design. This is absolutely false. This talk: https://www.youtube.com/watch?v=3OgbQOsW61Y 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.

corethree 3y ago
That's not theory. It's just a bunch of opinions. 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.
- RangerScience 3y ago
  Alright, what’s your criteria for a “theory”? Similarly, what’s your criteria for “program design”? I want to have a better idea of the goal posts that you’re setting.
  - corethree 3y ago
    formal theory is the full term. https://www.wikiwand.com/en/Formal_theory https://www.wikiwand.com/en/Formal_theory The first three definitions fit. 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. Check this resource if you're interested: https://www4.di.uminho.pt/~jno/ps/pdbc.pdf https://www4.di.uminho.pt/~jno/ps/pdbc.pdf 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.

sz4kerto 3y ago

Refactoring is generally not about the code style, or changing the design for its own sake. Refactoring happens because the model of the world that the software works with has changed since the software has been implemented. Maybe the way users and roles are represented was kinda OK 5 years ago, but the world (== business environment, understanding, requirements) has changed since. So the code that has been OK 5 years ago is painfully mismatched with the present. That's when refactoring is needed. Also. Tech debt is usually (not always) the marginal cost of the next feature. If new features cost X, and engineers are convinced that features could cost much less if the software was organised differently, then it might be useful to calculate the cost of a refactor.

corethree 3y ago
>Refactoring happens because the model of the world that the software works with has changed since the software has been implemented. Maybe the way users and roles are represented was kinda OK 5 years ago, but the world (== business environment, understanding, requirements) has changed since. So the code that has been OK 5 years ago is painfully mismatched with the present. Totally agreed. This is a practical reason for it. But much of refactoring doesn't happen because of this. The article says you should refactor all the time for "better" code. It's not talking about your use case where you have to update dependencies, security features and things like that.