3 ms·

I hated UML because it felt like someone "very important" had issued a commandment from that unless you did software with UML then you were DOING IT WRONG (spok

I hated UML because it felt like someone "very important" had issued a commandment from that unless you did software with UML then you were DOING IT WRONG (spoken in a booming voice from the sky). It felt super academic and "Thoughtworks"ish and Javaish and made software development boring instead of dynamic and fun. Glad its gone.

29athrowaway 4y ago
- deleted 4y ago
  [deleted]
- zozbot234 4y ago
  I'm not sure where this notion of UML diagrams as a silver bullet against technical debt is coming from. The whole OOAD development methodology that UML adoption was predicated on is the opposite of serious or rigorous; you can't just translate domain-level "objects" into a design and expect to end up with something sensible, that's not how it works. (In fact, unless some well-defined part of a system really has meaningful invariants that it cares about and should preserve, there's arguably not much of a real reason to even make an "object" out of it.)
  - im_down_w_otp 4y ago
    I tend to agree with this. If UML or something UML-like offers value in terms of understandability at some level of abstraction as a substitute for needing to hold the detailed mental model of the entire explicit implementation in one's head, then using it as something extracted from the implementation to provide a simplified sketch of it makes more sense than using it as an input artifact to creating the implementation.
  - 29athrowaway 4y ago
    - zozbot234 4y ago
      This might be relevant if UML made software easier to survey, review and/or audit. I don't expect this to be the case. (Which is not to say that other plausible solutions don't exist. For instance, an advanced type system often does a good job of surfacing the broad "design" of a piece of software.)
    - toast0 4y ago
      I get that there are worlds where formal methods are useful and excel. In my professional experience, nobody was willing to spend the time to write a formal specification (or much of any specification), because the specifications were subject to change at the whim of a hat. If there's no specification, there's no way to use formal methods. If there's no specification, producing UML makes even less sense than otherwise. How do you check if the UML matches the desired software? How do you check if the software matches the UML? How do you ensure the changes to the UML propagate to the software and vice versa? How do you examine the changes in the UML? Where are the case studies showing how UML was used successfully?
blub 4y ago
It’s not gone, it’s out there waiting for unsuspecting developers to pounce on. And what are you going to do, ask during the interview if the company uses UML? I mean who doesn’t use a little UML in a mid to big software company? Seems safer just to accept that one will come in contact with it and prepare for that day. I use it to document designs quite a lot myself.

29athrowaway 4y ago

deleted 4y ago
[deleted]
zozbot234 4y ago
I'm not sure where this notion of UML diagrams as a silver bullet against technical debt is coming from. The whole OOAD development methodology that UML adoption was predicated on is the opposite of serious or rigorous; you can't just translate domain-level "objects" into a design and expect to end up with something sensible, that's not how it works. (In fact, unless some well-defined part of a system really has meaningful invariants that it cares about and should preserve, there's arguably not much of a real reason to even make an "object" out of it.)
- im_down_w_otp 4y ago
  I tend to agree with this. If UML or something UML-like offers value in terms of understandability at some level of abstraction as a substitute for needing to hold the detailed mental model of the entire explicit implementation in one's head, then using it as something extracted from the implementation to provide a simplified sketch of it makes more sense than using it as an input artifact to creating the implementation.
- 29athrowaway 4y ago
  - zozbot234 4y ago
    This might be relevant if UML made software easier to survey, review and/or audit. I don't expect this to be the case. (Which is not to say that other plausible solutions don't exist. For instance, an advanced type system often does a good job of surfacing the broad "design" of a piece of software.)
  - toast0 4y ago
    I get that there are worlds where formal methods are useful and excel. In my professional experience, nobody was willing to spend the time to write a formal specification (or much of any specification), because the specifications were subject to change at the whim of a hat. If there's no specification, there's no way to use formal methods. If there's no specification, producing UML makes even less sense than otherwise. How do you check if the UML matches the desired software? How do you check if the software matches the UML? How do you ensure the changes to the UML propagate to the software and vice versa? How do you examine the changes in the UML? Where are the case studies showing how UML was used successfully?

blub 4y ago

It’s not gone, it’s out there waiting for unsuspecting developers to pounce on. And what are you going to do, ask during the interview if the company uses UML? I mean who doesn’t use a little UML in a mid to big software company? Seems safer just to accept that one will come in contact with it and prepare for that day. I use it to document designs quite a lot myself.