Ha :) "Or drawing UML diagrams (Here's a secret; no one does this.)"
Question: do they still insist on UML at university? I remember they did for me, and with ten years in IT I have never since seen a single UML document by anyone, much less created one.
Not sure what he meant by the XML bullet point, or the .NET under level editors. Using XML or JSON for a config file is trivial in most modern frameworks, like .NET (e.g. Unity).
> Question: do they still insist on UML at university?
I had a course [1] where the lecturer insisted on UML diagrams. And, even worse, they insisted on using a specific proprietary Java software and submitting the diagrams in that program's proprietary format.
Fortunately, my TA (who actually graded these diagrams) was much more lenient, but we had to do at least those UML diagrams that went up to the lecturer.
[1] The course was about applied development practices. Students were split into groups of 5 and had to develop a simple web application. It was really horrible; the lecturer had never heard of agile and forced us into a waterfall process in which 60% of the time was spent documenting requirements and drawing bogus diagrams.
> It was really horrible; the lecturer had never heard of agile and forced us into a waterfall process in which 60% of the time was spent documenting requirements and drawing bogus diagrams.
It sounds like the lecturer did an effective job of convincing people how valuable agile can be.
I find UML state diagrams useful for specific, localized bits of projects where it is not necessarily possible to hold the entire state machine in my mind while developing/interpreting the code. It acts as a spec to guide writing tests and tells future visitors to the codebase exactly what I was trying to do. I check the UML diagram into source control alongside the code, which contains comments pointing to the UML diagram.
The key is to use this sauce in limited amounts and only to guide the development of truly critical parts of your code. A utility library to convert dates? Eh. A core library that handles complex multiparty bid management for a market? Definitely.
UML would be handy at places where you would have drawn some kind of diagram anyway. Like an overview of components in a distributed system. Or a processing pipeline. Or an overview of a deployment environment. If UML delivered a useful set of constructs for those, it would be useful. Sadly, it focuses on class diagrams which I have never seen used anywhere. Sequence diagrams are somewhat used, but they are too complex and do not fit the average use-case well. (distinction between classes and objects? what about threads? loops have no break statement. Fragments are horrible. wtf.)
There are diagrams for component overview and such, but they are so strange that you just end up with drawing your own diagram type.
But yeah, the software engineering department still teaches UML.
I see and draw informal UML-lish diagrams on whiteboards and napkins. I'd say 90 percent of them are sort of like the class diagram in UML. The rest are sorta-collaboration-diagrams and maybe-sequence-diagrams.
We'd probably draw something similar even if UML never existed but I think it helped a bit in creating the common vocabulary. So I'd say there is some benefit to teaching UML at university.
The startup I worked in just after graduating (in dev web) last year used to work with UML diagrams. I then moved in bigger companies where it just disappeared.
Question: do they still insist on UML at university? I remember they did for me, and with ten years in IT I have never since seen a single UML document by anyone, much less created one.
Not sure what he meant by the XML bullet point, or the .NET under level editors. Using XML or JSON for a config file is trivial in most modern frameworks, like .NET (e.g. Unity).