8 ms·

So first, you should read their books for concrete code. Martin books, for example "refactoring" or "Enterprise architecture" actually have good code examples.

So first, you should read their books for concrete code. Martin books, for example "refactoring" or "Enterprise architecture" actually have good code examples. The same apply for kent beck early work on smalltalk (you can look at Junit) or his early work on the HotDraw editor (which was the source of many of the pattern in the Design Pattern book). Kent was one of the first adopter of smalltalk at the early 80 is techtronix, together with ward cunnighum (the inventor of wiki) and rebbeca swift brooks. Robert Martin work is mainly driven by his consulting practice and tend to change based on the on going trend. At the 2000's he was working with Grady Booch, preaching UML and design before coding. Later he dropped that in favour of agile and TDD. You do not see case studies since the industry simply does not really care. It is very trend prone. Most of the adopted advances were actually "hacks". For example C++ was invented out of necessity to create "C with objects" by a single person in AT&T labs. Unix was hacked in 3 weeks. Java was invented to program toasters, etc. Any attempt to develop tools and technique based on real research saw not adaptation - for example Ada at the 80s, UML at the 90's and early 2000, functional programming, TLA+ , etc.

geofft 7y ago
The question was about "research" in the meaning of quantitative scientific evidence that these proposed techniques make software delivery better in real-world conditions, not "research" in the sense of new ideas from academics. As a professional, I don't want UML because I've seen no evidence it actually helps. Show me relevant studies that it does and I will absolutely change my mind. (And there are plenty of things that industry does respect that came from academic research in the sense of new ideas. Rust, stereotypically the language of the trend-prone, draws on everything from Ada to functional programming. But unlike those it actually and demonstrably meets the needs of general-purpose programming in industry.)
- streetcat1 7y ago
  Sure. So UML is based on two main research areas - UML class diagram is based on rational algebra theory. A correct UML class diagram should follow the same normalization roles as defined by Codd seminal paper - "A Relational Model of Data for Large Shared Data Banks". You can ask, how does Prof Codd knows that this is is the correct way to describe and implement data. Well this follow directly from set theory. Again, how do we know that set theory works - well here we are the level of axioms of the set algebra. BTW, this Codd work was also "hacked" again by system R research which invented SQL. The other part of UML is based on finite state machine, which originated by Turning, and later refined by the work of David Harel on state charts. Again, those are theoretical CS tools. However, the work of Harel on state charts, was originated from the work on the Israel first aircarft (to be cancelled later), where he needed to define the the missile system. If you are interested on how those tool originated and later combined see the work of David Hay - "UML-Data-Modeling-Reconciliation" Those tools are useful in scale. For example, system with 3000 different use cases. Or for example you have 200 - 500 classes, each is a state machine. Again, since there is no software professional standard (not software engineering bar exam), you can or cannot use anything.
  - deleted 7y ago
    [deleted]
  - geofft 7y ago
    That's, again, not what I'm asking. I'm not asking for the theoretical underpinnings of why this is a good way to represent 200-500 classes. I'm asking why, if I and two coworkers need to code up 200-500 classes by next month to meet a promise to a customer, spending time on UML will make the customer happier. I have a programming language that itself has strong theoretical underpinnings. I also have a pretty good hunch that in about two weeks there will be a last-minute requirement that changes the structure of the data model, and in about three weeks there will be a production outage of another system that distracts my attention. Will UML help me deliver software with changing requirements faster and more accurately? How does it compare to other options in my toolbox, like using a less verbose language that doesn't have real OO (which in my experience is often the right choice) and because of its conciseness is easier to make major changes to? How do I tie the UML object structure to my programming language, and why is it better than using a strongly- and richly-typed language in the first place? Why do I see many successful software projects that as far as I can tell don't use UML?
    - streetcat1 7y ago
      First, I must say that the inventors of UML saw it as the last layer. The grand vision was a complete code generation from UML diagrams. And this was the overall grand vision that drove OO in general. I think that this is was happening now with the "low code" startups. The whole idea is to separate the global decisions (which are hard to change) - e.g. architecture, what classes, what each class do, from the local one (e.g. which data structure to use). So you would use UML for the global decisions, and than make programming the classes almost mechanical. Of course the customer do not see that. The customer see the user interface, and if the overall use cases are implemented correctly. Hence using those tool might help or not. Lets take architecture for example, why do people use an architect ?. Why does architect needs diagrams? Will the owner care of the architect use diagrams?
      - geofft 7y ago
- jhayward 7y ago
  I would be interested in a list of the tools you use daily and your list of research publications that prove that those specific tools improve productivity, reliability, or whatever metric you have named in selecting them.
  - geofft 7y ago
    That's a fair question, and it is absolutely fair and correct for you to imply that I don't have any. However, the comment above (which was not me) said "studies cited, case studies presented or concrete examples," not just studies. I was taking objection to the claim that merely coming out of academia counts as a "study" in this sense. I don't need an experimental study (though I would love to have one), a body of anecdotes of successful uses of a tool is sufficient. I can name countless case studies, concrete examples, and anecdotes of people using the programming languages and software environments I use successfully. There is a large body of evidence that, say, Linux works fine, whether or not a paper says as much. (And, in particular, there is a sizable body of anecdotal evidence that OpenStack does not work fine, and I've been pushing my team to find a migration strategy out of OpenStack for this exact reason.) Also, I think the burden of proof is on someone advocating for change. When I am delivering software successfully, and someone else comes in and says "You need to be taking this approach," I think it's fair for me to say "Why?", and that that's very different from staring blankly at bash and saying "Why?" and refusing to type anything. And finally I would actually be delighted to have real metrics for my tools. I do want to know if, say, enforcing style checks via pre-commit hooks makes development velocity faster and avoids annoying developers! It certainly seems like it would but it sounds like an easy enough thing to test, and I wish we as an industry (and more specifically people in either academia or industry who see their work as advocating for better software development practices, not developing software) would spend the time to test it.
- dingoegret 7y ago
  I feel like this enthrallment to studies is unhealthy and unproductive for discussion. Studies is not a synonym for truth. I could explain the limitations of studies and the historical errors they have contributed to, but I think that would be patronizing as most people on HN have discussed this ad nauseam. Also I think summoning evidence without specifying the details of the evidence you're seeking is extremely unhelpful. It just shuts down progress in a discussion. Some actions require hard evidence because the price of error is too great, but this isn't a court room and we are just floating ideas about a craft that is hard to quantitate. I understand your attitude. A lot has been written about software practices and rarely if ever is any of it backed up with data points.
chrisseaton 7y ago
I can see 'before' and 'after' code in their books. How do I know the 'after' code is any better in practice?
- rhizome31 7y ago
  You use your best judgement based on the context, as you usually do when developing software. The only thing you've gained by applying a documented pattern is a bit of help to write your commit message :-)
  - chrisseaton 7y ago
    > You use your best judgement based on the context This isn't how science is supposed to work. I work on programming language performance - when I say something could be implemented in a faster way, people don't just say 'yeah using my best judgement that'll be faster', they ask me to prove it. Otherwise I'm laughed off the stage. Why is it different for these people?
    - rhizome31 7y ago
      I might be wrong, but did Fowler pretend to follow the scientific method? I work on developing business web applications and Fowler's work has been very helpful to me, especially when I was a beginner. I still sometimes refer to PoEAA when picking up a framework that implements a pattern described there. However I'd be surprised if Fowler had anything useful to teach to someone working in your field.
      - chrisseaton 7y ago
        > did Fowler pretend to follow the scientific method His company calls him a 'scientist' - a 'chief scientist' no less - https://www.thoughtworks.com/profiles/martin-fowler https://www.thoughtworks.com/profiles/martin-fowler and presumably bills accordingly.
        7y ago
blub 7y ago
I read parts of the refactoring book (1st edition) when it came out to see what kind of refactorings the author mentions. Since I didn't remember much from it, I decided this year to take a look at the 2nd edition, which to my amusement is written in JavaScript. After reading the example refactoring at the beginning I abandoned the book, because it champions the "code as prose" idea, which is rightfully contradicted by Ousterhout in his "A Philosophy of Software Design". "Enterprise architecture" was not relevant for me, I wasn't doing any EA when I started reading it and quickly lost interest. The only potentially engaging topic was concurrency, but there are much better books available about that topic. "Pattern-Oriented Software Architecture" (I am only familiar with vol 1 & 2) has wider applicability and is more compelling in my opinion. And they have references and examples. For instance the Pipes & Filters architecture patterns gives UNIX [Bac86], CMS Pipelines [HRV95] and LASSPTools [Set95] as examples and references "The Pipeline Design Pattern" [VBT95]. I do see case studies and references, but not from these authors I mentioned.

geofft 7y ago

The question was about "research" in the meaning of quantitative scientific evidence that these proposed techniques make software delivery better in real-world conditions, not "research" in the sense of new ideas from academics. As a professional, I don't want UML because I've seen no evidence it actually helps. Show me relevant studies that it does and I will absolutely change my mind. (And there are plenty of things that industry does respect that came from academic research in the sense of new ideas. Rust, stereotypically the language of the trend-prone, draws on everything from Ada to functional programming. But unlike those it actually and demonstrably meets the needs of general-purpose programming in industry.)

streetcat1 7y ago
Sure. So UML is based on two main research areas - UML class diagram is based on rational algebra theory. A correct UML class diagram should follow the same normalization roles as defined by Codd seminal paper - "A Relational Model of Data for Large Shared Data Banks". You can ask, how does Prof Codd knows that this is is the correct way to describe and implement data. Well this follow directly from set theory. Again, how do we know that set theory works - well here we are the level of axioms of the set algebra. BTW, this Codd work was also "hacked" again by system R research which invented SQL. The other part of UML is based on finite state machine, which originated by Turning, and later refined by the work of David Harel on state charts. Again, those are theoretical CS tools. However, the work of Harel on state charts, was originated from the work on the Israel first aircarft (to be cancelled later), where he needed to define the the missile system. If you are interested on how those tool originated and later combined see the work of David Hay - "UML-Data-Modeling-Reconciliation" Those tools are useful in scale. For example, system with 3000 different use cases. Or for example you have 200 - 500 classes, each is a state machine. Again, since there is no software professional standard (not software engineering bar exam), you can or cannot use anything.
- deleted 7y ago
  [deleted]
- geofft 7y ago
  That's, again, not what I'm asking. I'm not asking for the theoretical underpinnings of why this is a good way to represent 200-500 classes. I'm asking why, if I and two coworkers need to code up 200-500 classes by next month to meet a promise to a customer, spending time on UML will make the customer happier. I have a programming language that itself has strong theoretical underpinnings. I also have a pretty good hunch that in about two weeks there will be a last-minute requirement that changes the structure of the data model, and in about three weeks there will be a production outage of another system that distracts my attention. Will UML help me deliver software with changing requirements faster and more accurately? How does it compare to other options in my toolbox, like using a less verbose language that doesn't have real OO (which in my experience is often the right choice) and because of its conciseness is easier to make major changes to? How do I tie the UML object structure to my programming language, and why is it better than using a strongly- and richly-typed language in the first place? Why do I see many successful software projects that as far as I can tell don't use UML?
  - streetcat1 7y ago
    First, I must say that the inventors of UML saw it as the last layer. The grand vision was a complete code generation from UML diagrams. And this was the overall grand vision that drove OO in general. I think that this is was happening now with the "low code" startups. The whole idea is to separate the global decisions (which are hard to change) - e.g. architecture, what classes, what each class do, from the local one (e.g. which data structure to use). So you would use UML for the global decisions, and than make programming the classes almost mechanical. Of course the customer do not see that. The customer see the user interface, and if the overall use cases are implemented correctly. Hence using those tool might help or not. Lets take architecture for example, why do people use an architect ?. Why does architect needs diagrams? Will the owner care of the architect use diagrams?
    - geofft 7y ago
jhayward 7y ago
I would be interested in a list of the tools you use daily and your list of research publications that prove that those specific tools improve productivity, reliability, or whatever metric you have named in selecting them.
- geofft 7y ago
  That's a fair question, and it is absolutely fair and correct for you to imply that I don't have any. However, the comment above (which was not me) said "studies cited, case studies presented or concrete examples," not just studies. I was taking objection to the claim that merely coming out of academia counts as a "study" in this sense. I don't need an experimental study (though I would love to have one), a body of anecdotes of successful uses of a tool is sufficient. I can name countless case studies, concrete examples, and anecdotes of people using the programming languages and software environments I use successfully. There is a large body of evidence that, say, Linux works fine, whether or not a paper says as much. (And, in particular, there is a sizable body of anecdotal evidence that OpenStack does not work fine, and I've been pushing my team to find a migration strategy out of OpenStack for this exact reason.) Also, I think the burden of proof is on someone advocating for change. When I am delivering software successfully, and someone else comes in and says "You need to be taking this approach," I think it's fair for me to say "Why?", and that that's very different from staring blankly at bash and saying "Why?" and refusing to type anything. And finally I would actually be delighted to have real metrics for my tools. I do want to know if, say, enforcing style checks via pre-commit hooks makes development velocity faster and avoids annoying developers! It certainly seems like it would but it sounds like an easy enough thing to test, and I wish we as an industry (and more specifically people in either academia or industry who see their work as advocating for better software development practices, not developing software) would spend the time to test it.
dingoegret 7y ago
I feel like this enthrallment to studies is unhealthy and unproductive for discussion. Studies is not a synonym for truth. I could explain the limitations of studies and the historical errors they have contributed to, but I think that would be patronizing as most people on HN have discussed this ad nauseam. Also I think summoning evidence without specifying the details of the evidence you're seeking is extremely unhelpful. It just shuts down progress in a discussion. Some actions require hard evidence because the price of error is too great, but this isn't a court room and we are just floating ideas about a craft that is hard to quantitate. I understand your attitude. A lot has been written about software practices and rarely if ever is any of it backed up with data points.

chrisseaton 7y ago

I can see 'before' and 'after' code in their books. How do I know the 'after' code is any better in practice?

rhizome31 7y ago
You use your best judgement based on the context, as you usually do when developing software. The only thing you've gained by applying a documented pattern is a bit of help to write your commit message :-)
- chrisseaton 7y ago
  > You use your best judgement based on the context This isn't how science is supposed to work. I work on programming language performance - when I say something could be implemented in a faster way, people don't just say 'yeah using my best judgement that'll be faster', they ask me to prove it. Otherwise I'm laughed off the stage. Why is it different for these people?
  - rhizome31 7y ago
    I might be wrong, but did Fowler pretend to follow the scientific method? I work on developing business web applications and Fowler's work has been very helpful to me, especially when I was a beginner. I still sometimes refer to PoEAA when picking up a framework that implements a pattern described there. However I'd be surprised if Fowler had anything useful to teach to someone working in your field.
    - chrisseaton 7y ago
      > did Fowler pretend to follow the scientific method His company calls him a 'scientist' - a 'chief scientist' no less - https://www.thoughtworks.com/profiles/martin-fowler https://www.thoughtworks.com/profiles/martin-fowler and presumably bills accordingly.
      - 7y ago

blub 7y ago

I read parts of the refactoring book (1st edition) when it came out to see what kind of refactorings the author mentions. Since I didn't remember much from it, I decided this year to take a look at the 2nd edition, which to my amusement is written in JavaScript. After reading the example refactoring at the beginning I abandoned the book, because it champions the "code as prose" idea, which is rightfully contradicted by Ousterhout in his "A Philosophy of Software Design". "Enterprise architecture" was not relevant for me, I wasn't doing any EA when I started reading it and quickly lost interest. The only potentially engaging topic was concurrency, but there are much better books available about that topic. "Pattern-Oriented Software Architecture" (I am only familiar with vol 1 & 2) has wider applicability and is more compelling in my opinion. And they have references and examples. For instance the Pipes & Filters architecture patterns gives UNIX [Bac86], CMS Pipelines [HRV95] and LASSPTools [Set95] as examples and references "The Pipeline Design Pattern" [VBT95]. I do see case studies and references, but not from these authors I mentioned.