3 ms·

Software development doesn't need to be an art and it doesn't need to be a science either. By science I mean using data and statistical evidence to drive devel

Software development doesn't need to be an art and it doesn't need to be a science either. By science I mean using data and statistical evidence to drive development, by Art I mean using your gut and your intuition to drive development. A computer is a deterministic system. It is 100% predictable and follows an exact set of rules. Software development is amenable to proof, logic and theory. You don't need to make decisions driven by data or your gut if the problem space can be described by a logical and axiomatic theory. The problem is that the current "theory" is incomplete and not all parts of systems are amenable to statistical measurement. Thus a proper system architect needs to unify Theory, Science and Art to form a cohesive framework of system architecture. Theory is priority because it says definitive things about the system, Science is secondary and operates as a data driven backup for places theory is currently incomplete, and Art is basically the catch all admission that there is no data or theory to back up the problem space and you're just going to have to rely on your intuition. The problem with Martin Fowler is that all his stuff is 100% Art. It's just made up stuff from intuition and buzz words. Art is largely ad-hoc and does involve a lot of guess work that is often wrong. People identify with Martin Fowlers stuff because they identify with it on the "gut" level. It "feels" right. Your feelings are not a good way to do engineering, you rely only on intuition when you have no choice. Fowler is also a big Object Oriented Architect. The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art. The pattern is starting to fall out of favor because people are realizing that they tend to build over-complicated systems when following the pattern because they are largely just relying on their gut intuition to build these things using primitives that are validated by the same flawed intuition.

streetcat1 7y ago
> The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art. Absolutely incorrect. The data part of OO is based on set theory as formalised in the database design research and type systems. The dynamic part of OO is based on finite state machines. The data abstraction and information hiding part is based on the work of barbara liskov (for which she won the Turing award) - https://en.wikipedia.org/wiki/Barbara_Liskov https://en.wikipedia.org/wiki/Barbara_Liskov
- crimsonalucard 7y ago
  >Absolutely incorrect. I said OO didn't have basis in theory or science. By basis I mean it wasn't derived from theory. Rather it was created as more of an "artistic" endeavor and later it was fit into a framework of an existing theory. You should know almost ANY system can be broken down to fit into an existing theory from a projectile object, to a flying plane, to the weather, to an object oriented programming language. Thus following that line of thought ANYTHING can be a part of a theory but I use the term "basis" to emphasize that something can be derived out of theory. >The data part of OO is based on set theory as formalised in the database design research and type systems. I highly disagree. Type systems are not exclusive to OO, additionally the OO type system allows for mutation which is basically not at all part of set theory at all. Also type systems and database systems didn't formalize set theory. Set theory comes from mathematics. >The dynamic part of OO is based on finite state machines. This I can agree. A state machine modifies a change of state which is closer to the definition of an object in OOP. >The data abstraction and information hiding part is based on the work of barbara liskov (for which she won the Turing award) - https://en.wikipedia.org/wiki/Barbara_Liskov https://en.wikipedia.org/wiki/Barbara_Liskov This has more to do with the type system then it does with OOP. Also note if you read the paper. Her paper has no data, statistics, formal theory, rigor, theorems, proofs or axioms. So although she won the turing award, although this is a research paper... it is largely "artistic" in the sense I defined it. See the paper here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.3043&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136... Note that her paper is important, I am not discounting it. But it is largely more in the realm of design then it is in the realm of theory and science.
  - streetcat1 7y ago
    She developed the axiomatic theory in a later book: https://mitpress.mit.edu/books/abstraction-and-specification-program-development https://mitpress.mit.edu/books/abstraction-and-specification... Were she propose an axiomatic theory for OO interface design. Definitely not artistic. The only thing artistic in OO (as someone who practice it in the last 30 years), is finding the initial set of objects. But you will have this issue with any technique.
perlgeek 7y ago
> A computer is a deterministic system. It is 100% predictable and follows an exact set of rules. Software development is amenable to proof, logic and theory. You don't need to make decisions driven by data or your gut if the problem space can be described by a logical and axiomatic theory. That's true, only if you can assume perfect knowledge about the problems/requirements, the data, the environment, and how (if at all) those will change. In practice, none of these tend to be true, and that is where a lot of gut feeling will come in. An experienced practitioner will just know that certain modules / feature sets will grow and grow and grow over time, and will take special care to build a particular robust approach for that area. Or that certain kinds of data are often of low quality.
- crimsonalucard 7y ago
  Yes this is where the "Art" that I described also comes into play. We have no theory that can predict the output of a human brain therefore we can't theoretically derive what requirements a customer will want or change over a span of time. However... There is something sort of new from the academic side that could potentially be a theory that can deal with problem you describe. At a high level the theory looks almost like a formal language for "design" and "abstraction." It's called category theory. It's new-ish so it doesn't yet solve the problem you describe but I see the outlines of it within the framework of the theory.
  - perlgeek 7y ago
    What's the relation between category theory and changing requirements? You lost me there...
    - crimsonalucard 7y ago
      An example: Since category theory looks almost like a formal theory of "design" and "abstraction" is looks like if one day someone could come up with an algorithm or function to formally derive a solution given a set of requirements. To anticipate changing requirements you simply need to adjust the initial set of requirements to be more broader and then this hypothetical function would output a system that can handle potential changes that you anticipated. This is all hand-wavy and not concrete. Many people who study CT see it as currently the closest thing to a formal theory of "design" and "abstraction." If this is true then techniques or algorithms for deriving architectures of systems can become turn key. Of course let me emphasize, I'm just speculating here. Not talking about anything that actually exists. Just saying that if you study CT you can kind of see this kind of thing existing sometime in the future.

streetcat1 7y ago

> The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art. Absolutely incorrect. The data part of OO is based on set theory as formalised in the database design research and type systems. The dynamic part of OO is based on finite state machines. The data abstraction and information hiding part is based on the work of barbara liskov (for which she won the Turing award) - https://en.wikipedia.org/wiki/Barbara_Liskov https://en.wikipedia.org/wiki/Barbara_Liskov

crimsonalucard 7y ago
>Absolutely incorrect. I said OO didn't have basis in theory or science. By basis I mean it wasn't derived from theory. Rather it was created as more of an "artistic" endeavor and later it was fit into a framework of an existing theory. You should know almost ANY system can be broken down to fit into an existing theory from a projectile object, to a flying plane, to the weather, to an object oriented programming language. Thus following that line of thought ANYTHING can be a part of a theory but I use the term "basis" to emphasize that something can be derived out of theory. >The data part of OO is based on set theory as formalised in the database design research and type systems. I highly disagree. Type systems are not exclusive to OO, additionally the OO type system allows for mutation which is basically not at all part of set theory at all. Also type systems and database systems didn't formalize set theory. Set theory comes from mathematics. >The dynamic part of OO is based on finite state machines. This I can agree. A state machine modifies a change of state which is closer to the definition of an object in OOP. >The data abstraction and information hiding part is based on the work of barbara liskov (for which she won the Turing award) - https://en.wikipedia.org/wiki/Barbara_Liskov https://en.wikipedia.org/wiki/Barbara_Liskov This has more to do with the type system then it does with OOP. Also note if you read the paper. Her paper has no data, statistics, formal theory, rigor, theorems, proofs or axioms. So although she won the turing award, although this is a research paper... it is largely "artistic" in the sense I defined it. See the paper here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.3043&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136... Note that her paper is important, I am not discounting it. But it is largely more in the realm of design then it is in the realm of theory and science.
- streetcat1 7y ago
  She developed the axiomatic theory in a later book: https://mitpress.mit.edu/books/abstraction-and-specification-program-development https://mitpress.mit.edu/books/abstraction-and-specification... Were she propose an axiomatic theory for OO interface design. Definitely not artistic. The only thing artistic in OO (as someone who practice it in the last 30 years), is finding the initial set of objects. But you will have this issue with any technique.

perlgeek 7y ago

> A computer is a deterministic system. It is 100% predictable and follows an exact set of rules. Software development is amenable to proof, logic and theory. You don't need to make decisions driven by data or your gut if the problem space can be described by a logical and axiomatic theory. That's true, only if you can assume perfect knowledge about the problems/requirements, the data, the environment, and how (if at all) those will change. In practice, none of these tend to be true, and that is where a lot of gut feeling will come in. An experienced practitioner will just know that certain modules / feature sets will grow and grow and grow over time, and will take special care to build a particular robust approach for that area. Or that certain kinds of data are often of low quality.

crimsonalucard 7y ago
Yes this is where the "Art" that I described also comes into play. We have no theory that can predict the output of a human brain therefore we can't theoretically derive what requirements a customer will want or change over a span of time. However... There is something sort of new from the academic side that could potentially be a theory that can deal with problem you describe. At a high level the theory looks almost like a formal language for "design" and "abstraction." It's called category theory. It's new-ish so it doesn't yet solve the problem you describe but I see the outlines of it within the framework of the theory.
- perlgeek 7y ago
  What's the relation between category theory and changing requirements? You lost me there...
  - crimsonalucard 7y ago
    An example: Since category theory looks almost like a formal theory of "design" and "abstraction" is looks like if one day someone could come up with an algorithm or function to formally derive a solution given a set of requirements. To anticipate changing requirements you simply need to adjust the initial set of requirements to be more broader and then this hypothetical function would output a system that can handle potential changes that you anticipated. This is all hand-wavy and not concrete. Many people who study CT see it as currently the closest thing to a formal theory of "design" and "abstraction." If this is true then techniques or algorithms for deriving architectures of systems can become turn key. Of course let me emphasize, I'm just speculating here. Not talking about anything that actually exists. Just saying that if you study CT you can kind of see this kind of thing existing sometime in the future.