5 ms·

Do the business requirements (fundamental assumptions around design to be more generic) of a bridge, car or airliner change dramatically over time? I'd argue n

Do the business requirements (fundamental assumptions around design to be more generic) of a bridge, car or airliner change dramatically over time? I'd argue not. Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive.

corethree 3y ago
>Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive. What formal theory have you ever used for designing your software? I would argue you've never used anything. Every abstraction you've ever made was likely a gut feeling, an instinct or following some vague hand wavy rule of thumb. At best we use type theory for type correctness and complexity theory to calculate efficiency. That's basically as far as it goes with "theory" and these two things aren't even about "software design". Software design in practice as most engineers use it today is, practically speaking (key phrase), 100% art. Sometimes people come up with big fancy words like "dependency injection" or stupid Acronyms like SOLID to create the illusion of formal theory, but these things are nothing of the sort. It's just tips and tricks. The plane, the car, the bridge? Those things use both design and formal theory... software design as most engineers use it, again, does not use ANY formal theory, it's almost just purely design all the way down.
- lvturner 3y ago
  Just because it doesn't use formal theory now --- does not mean it/we shouldn't use it. I'm talking about needs, not haves.
  - corethree 3y ago
    Well in all other engineering fields although they are used in conjunction. The two concepts are practically more or less mutually exclusive. There's no room for "design" when finding the shortest distance between two points because the shortest distance between two points is done via calculation using formal theory. Things like user-friendliness can be "philosophical". You can separately and selectively apply theory and design where applicable, but they cannot in actuality be unionized in some unholy grafting. I would say for the topic at hand; Of how to organize and abstract your code, if we ever find a complete formal theory for that, much of design will go out the window and what's left is mostly a calculation.
    - lvturner 3y ago
      I see what you are driving at and I think we are looking at the problem from slightly different lenses yet still drawing much the same conclusions. There's no room for design in finding the shortest distance between two points, but there is room for design in picking which points you wish to find the distance on -- I think perhaps for meaningful discussion on this specific topic my definition of "Software Design" is too broad-scope ;)
      - corethree 3y ago
        Sort of but I think you're too limiting on the scope of what theory can do. Usually in engineering you can't just design anything in your imagination. You have a limited set. A domain. Which to continue the theme of the example, I have a set of points. I rarely have all the points on the face of the earth. How do I pick the point such that it minimizes a specification constraint? Let's say that constraint is the shortest distance. This is design by calculation. Then design is out of the equation. But if the specification constrains is "The two points most pleasing to the user" Then you can "design" those points. If I had access to every neuron and had a exact fully realized mathematical model of the general human brain, even this constraint of "pleasing" and "usability", in theory could be met with a calculation. Largely anything that leans more towards "design" means we don't know shit about what's going on so we hire philosophers and artists to make wild guesses. That is essentially what design is: a wild guess. The more of software we can model in a theory, the less wild guesses we need.
- agent327 3y ago
  Aren't you being overly optimistic about the engineering disciplines' ability to compute things? How does engineering work: do you sit down with a spec (say, "create a wing that can lift a passenger plane"), and then run some formulas, and end up with a wing? Or do you propose a wing, based on past experience (rough shape and size), and _then_ bring in computation to make sure it provides the correct amount of lift, iterating through designs as you go? Because I think it's really the last one. There is no formula to design a bridge: you design the bridge, and then use formulas and lookup tables to validate it is strong enough. Same for pretty much anything else produced by any engineering discipline. So in that sense, engineering and programming aren't all that far apart: both start from past experience, and use various validation methods after a design has been proposed, iterating through designs to reach an optimal state. Software engineering, being a younger discipline, is still working on validation methods, and many practitioners find they simply have no budget to apply them (nor any life-or-death constraints that force them to). That's ok though. If you design a new can opener you aren't going through all the processes that apply to an airliner either.
  - corethree 3y ago
    No. theory is very much part of the creation of the bridge. It is not just for verification. If you read more carefully. What I am saying is that in software engineering, there is no theory. It's all Design. All made up. There's also no verification of the design itself.
    - nuancebydefault 3y ago
      > There's no verification of the design itself. I think this is mostly a philosophical statement, but it certainly has truth to it. Code reviews / rework tackle mostly the code, but not the fundamental design. However the execution of the code tackles the design as well: - If the design is wrong, the result is bad, that is detected at the execution phase. - If the design is suboptimal (hard to maintain or extend, bad cpu load, hard to reuse...), well that is usually not solved. IMO that matches your point.
      - 3y ago
ludston 3y ago
Mathematics and science can both be viewed as very fleshed out and practical branches philosophy, so they certainly aren't mutually exclusive.
- corethree 3y ago
  Everything on the face of the earth falls under philosophy. It's the biggest non-category ever. I'm basically talking about "philosophy" the way the book uses the word. Which in short is just the authors opinionated take on software masquerading as something a bit more "official" then just an opinion. I mean would you call your own opinions on software design a "philosophy"?
  - ludston 3y ago
    Yes probably. The only real difference between an opinion and a philosophy are the number of people that believe it.
    - corethree 3y ago
      Right, what about "formal theory"? Let's say number theory? That's a concept independent of belief. And that's the difference I'm getting at here.
      - ludston 3y ago
        Formal theories are not independent of belief at all! They are based upon axioms, which are the beliefs that must be true in order for the formal theory to be useful.
        corethree 3y ago
        I agree. But then what is the difference between religion and an axiom? Both are beliefs. Are you saying there is no difference? Maybe technically there is no difference. But clearly from the practical perspective there's a huge mutually exclusive difference. We should not merge GOF design patterns and SOLID or any other made up "software religion" with a formal theory. That's what I mean by "belief"

corethree 3y ago

>Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive. What formal theory have you ever used for designing your software? I would argue you've never used anything. Every abstraction you've ever made was likely a gut feeling, an instinct or following some vague hand wavy rule of thumb. At best we use type theory for type correctness and complexity theory to calculate efficiency. That's basically as far as it goes with "theory" and these two things aren't even about "software design". Software design in practice as most engineers use it today is, practically speaking (key phrase), 100% art. Sometimes people come up with big fancy words like "dependency injection" or stupid Acronyms like SOLID to create the illusion of formal theory, but these things are nothing of the sort. It's just tips and tricks. The plane, the car, the bridge? Those things use both design and formal theory... software design as most engineers use it, again, does not use ANY formal theory, it's almost just purely design all the way down.

lvturner 3y ago
Just because it doesn't use formal theory now --- does not mean it/we shouldn't use it. I'm talking about needs, not haves.
- corethree 3y ago
  Well in all other engineering fields although they are used in conjunction. The two concepts are practically more or less mutually exclusive. There's no room for "design" when finding the shortest distance between two points because the shortest distance between two points is done via calculation using formal theory. Things like user-friendliness can be "philosophical". You can separately and selectively apply theory and design where applicable, but they cannot in actuality be unionized in some unholy grafting. I would say for the topic at hand; Of how to organize and abstract your code, if we ever find a complete formal theory for that, much of design will go out the window and what's left is mostly a calculation.
  - lvturner 3y ago
    I see what you are driving at and I think we are looking at the problem from slightly different lenses yet still drawing much the same conclusions. There's no room for design in finding the shortest distance between two points, but there is room for design in picking which points you wish to find the distance on -- I think perhaps for meaningful discussion on this specific topic my definition of "Software Design" is too broad-scope ;)
    - corethree 3y ago
      Sort of but I think you're too limiting on the scope of what theory can do. Usually in engineering you can't just design anything in your imagination. You have a limited set. A domain. Which to continue the theme of the example, I have a set of points. I rarely have all the points on the face of the earth. How do I pick the point such that it minimizes a specification constraint? Let's say that constraint is the shortest distance. This is design by calculation. Then design is out of the equation. But if the specification constrains is "The two points most pleasing to the user" Then you can "design" those points. If I had access to every neuron and had a exact fully realized mathematical model of the general human brain, even this constraint of "pleasing" and "usability", in theory could be met with a calculation. Largely anything that leans more towards "design" means we don't know shit about what's going on so we hire philosophers and artists to make wild guesses. That is essentially what design is: a wild guess. The more of software we can model in a theory, the less wild guesses we need.
agent327 3y ago
Aren't you being overly optimistic about the engineering disciplines' ability to compute things? How does engineering work: do you sit down with a spec (say, "create a wing that can lift a passenger plane"), and then run some formulas, and end up with a wing? Or do you propose a wing, based on past experience (rough shape and size), and _then_ bring in computation to make sure it provides the correct amount of lift, iterating through designs as you go? Because I think it's really the last one. There is no formula to design a bridge: you design the bridge, and then use formulas and lookup tables to validate it is strong enough. Same for pretty much anything else produced by any engineering discipline. So in that sense, engineering and programming aren't all that far apart: both start from past experience, and use various validation methods after a design has been proposed, iterating through designs to reach an optimal state. Software engineering, being a younger discipline, is still working on validation methods, and many practitioners find they simply have no budget to apply them (nor any life-or-death constraints that force them to). That's ok though. If you design a new can opener you aren't going through all the processes that apply to an airliner either.
- corethree 3y ago
  No. theory is very much part of the creation of the bridge. It is not just for verification. If you read more carefully. What I am saying is that in software engineering, there is no theory. It's all Design. All made up. There's also no verification of the design itself.
  - nuancebydefault 3y ago
    > There's no verification of the design itself. I think this is mostly a philosophical statement, but it certainly has truth to it. Code reviews / rework tackle mostly the code, but not the fundamental design. However the execution of the code tackles the design as well: - If the design is wrong, the result is bad, that is detected at the execution phase. - If the design is suboptimal (hard to maintain or extend, bad cpu load, hard to reuse...), well that is usually not solved. IMO that matches your point.
    - 3y ago

ludston 3y ago

Mathematics and science can both be viewed as very fleshed out and practical branches philosophy, so they certainly aren't mutually exclusive.

corethree 3y ago
Everything on the face of the earth falls under philosophy. It's the biggest non-category ever. I'm basically talking about "philosophy" the way the book uses the word. Which in short is just the authors opinionated take on software masquerading as something a bit more "official" then just an opinion. I mean would you call your own opinions on software design a "philosophy"?
- ludston 3y ago
  Yes probably. The only real difference between an opinion and a philosophy are the number of people that believe it.
  - corethree 3y ago
    Right, what about "formal theory"? Let's say number theory? That's a concept independent of belief. And that's the difference I'm getting at here.
    - ludston 3y ago
      Formal theories are not independent of belief at all! They are based upon axioms, which are the beliefs that must be true in order for the formal theory to be useful.
      - corethree 3y ago
        I agree. But then what is the difference between religion and an axiom? Both are beliefs. Are you saying there is no difference? Maybe technically there is no difference. But clearly from the practical perspective there's a huge mutually exclusive difference. We should not merge GOF design patterns and SOLID or any other made up "software religion" with a formal theory. That's what I mean by "belief"