4 ms·

The question was about "research" in the meaning of quantitative scientific evidence that these proposed techniques make software delivery better in real-world

by 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
      Again, I am not asking how to use UML, or why the inventors of UML designed it in a certain way, or why it sounds like it could be a good idea, or whether there are other systems like UML that are good ideas (I can just use those systems directly then!). I am asking what evidence there is that UML helps me deliver better products more efficiently. Are there successful software projects that do this complete code generation thing (and how do they compare to directly writing real code in more efficient programming languages with rich typesystems)? Are there development efforts where giving up and deciding that certain architectural elements are hard to change has been the right approach (in my experience it generally never is)? What are their names? Do they have experience reports? Are there numbers? I am looking for, at the least, a specific name like "The Chrysler Comprehensive Compensation System took these approaches to development." (But hopefully not a massive and expensive failure like C3.)
- traderjane 7y ago
  geoftt isn’t asking whether metaphorical TLA+ is academically fruitful. He’s asking if Amazons et al. have _continued_ to use it, and whether there’s some volume of evidence attesting to this.
  - streetcat1 7y ago
    Sure. So if amazon did not continue to use it. Does TLA+ suddenly become not useful? My point here is that those tools are theoretical CS tools based on the underlying nature of computers - which are a discrete digital state machine. Why do you even use high level languages, why not just program in assembler?
    - traderjane 7y ago
      If the Amazons of the world tried and dropped TLA+, that is signal to people who were on edge of technological adoption. If we received data on its efficacy during its trials, we'd be even more informed, as people are interested in more than the internal consistency of a system. Right now some people have a theory that Uncle Bob is noise in the sea of architectural opinion, and we can't move forward because we don't have enough data. The call for more data is welcome by me.
      - spenczar5 7y ago
        Amazon continues to use TLA+. I work there. It's not a tool needed every day, and it's not needed by everyone (really, not by almost _anyone_). But sometimes it's the best tool for the job. You won't be getting much data on this because companies are secretive. The way it's used is to ensure correctness of distributed systems. A classic example might be ensuring that a model for backing up customer data is unable to get into indeterminate state. It's important to get the model right. But the model isn't code - TLA is not a programming language, it's a tool for modeling state machines; yes, of course, one needs to also write software to deliver value.
    - geofft 7y ago
      > Sure. So if amazon did not continue to use it. Does TLA+ suddenly become not useful? Yes. (Or more precisely, it never was useful.) Zero part of my business requirements involve anything about discrete digital state machines. If I could deliver business value more efficiently with pen and paper, I would. If I could deliver business value more efficiently with Excel or a shell one-liner, I would (and do). If I could deliver business value more efficiently by singing my harmony into the Music of the Ainur, I would. I write software because it's the tool we've found that is most efficient at delivering business value, not because the software itself has value. So I use high-level languages because they are demonstrably more efficient. (And I frequently write sloppy code in Python or awk because it helps me answer business-relevant questions like "why is the site slow" quickly, without demanding I be rigorous about my software engineering in the process of answering the question.) don't use UML because I have yet to see evidence that it will help me deliver business value more effectively. (I do also enjoy writing software as a practice, and I do that on weekends. That's the time to make code for code's sake.)
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.

by geofft 7y ago

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
    Again, I am not asking how to use UML, or why the inventors of UML designed it in a certain way, or why it sounds like it could be a good idea, or whether there are other systems like UML that are good ideas (I can just use those systems directly then!). I am asking what evidence there is that UML helps me deliver better products more efficiently. Are there successful software projects that do this complete code generation thing (and how do they compare to directly writing real code in more efficient programming languages with rich typesystems)? Are there development efforts where giving up and deciding that certain architectural elements are hard to change has been the right approach (in my experience it generally never is)? What are their names? Do they have experience reports? Are there numbers? I am looking for, at the least, a specific name like "The Chrysler Comprehensive Compensation System took these approaches to development." (But hopefully not a massive and expensive failure like C3.)
traderjane 7y ago
geoftt isn’t asking whether metaphorical TLA+ is academically fruitful. He’s asking if Amazons et al. have _continued_ to use it, and whether there’s some volume of evidence attesting to this.
- streetcat1 7y ago
  Sure. So if amazon did not continue to use it. Does TLA+ suddenly become not useful? My point here is that those tools are theoretical CS tools based on the underlying nature of computers - which are a discrete digital state machine. Why do you even use high level languages, why not just program in assembler?
  - traderjane 7y ago
    If the Amazons of the world tried and dropped TLA+, that is signal to people who were on edge of technological adoption. If we received data on its efficacy during its trials, we'd be even more informed, as people are interested in more than the internal consistency of a system. Right now some people have a theory that Uncle Bob is noise in the sea of architectural opinion, and we can't move forward because we don't have enough data. The call for more data is welcome by me.
    - spenczar5 7y ago
      Amazon continues to use TLA+. I work there. It's not a tool needed every day, and it's not needed by everyone (really, not by almost _anyone_). But sometimes it's the best tool for the job. You won't be getting much data on this because companies are secretive. The way it's used is to ensure correctness of distributed systems. A classic example might be ensuring that a model for backing up customer data is unable to get into indeterminate state. It's important to get the model right. But the model isn't code - TLA is not a programming language, it's a tool for modeling state machines; yes, of course, one needs to also write software to deliver value.
  - geofft 7y ago
    > Sure. So if amazon did not continue to use it. Does TLA+ suddenly become not useful? Yes. (Or more precisely, it never was useful.) Zero part of my business requirements involve anything about discrete digital state machines. If I could deliver business value more efficiently with pen and paper, I would. If I could deliver business value more efficiently with Excel or a shell one-liner, I would (and do). If I could deliver business value more efficiently by singing my harmony into the Music of the Ainur, I would. I write software because it's the tool we've found that is most efficient at delivering business value, not because the software itself has value. So I use high-level languages because they are demonstrably more efficient. (And I frequently write sloppy code in Python or awk because it helps me answer business-relevant questions like "why is the site slow" quickly, without demanding I be rigorous about my software engineering in the process of answering the question.) don't use UML because I have yet to see evidence that it will help me deliver business value more effectively. (I do also enjoy writing software as a practice, and I do that on weekends. That's the time to make code for code's sake.)

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.