
Out with the UML: reimagining introductory courses in software engineering - ingve
https://iansommerville.com/systems-software-and-technology/2018/11/18/what-should-we-teach-in-software-engineering-courses/
======
erikpukinskis
Software Engineering tends to be taught as, like, Practical Professional
Software Development Tips.

And as a result software people seem to have no real concept of what
“Engineering” as practiced in all the traditional engineering disciplines is.

Neither do I probably, but from the outside it seems to be something like
“Learning how to work in such a way that the risk of known bad outcomes is
mitigated.”

In software, since it’s still a quite new material, changing often, people
seem to throw their hands in the air and just teach some common software
development practices and move on.

And yet, I see so many companies making the same mistakes, and promoting
managers who seem to fixate on their pet “bad outcome” to avoid while ignoring
all the others.

I can kind of imagine a proper engineering degree in software though. It would
probably be a whole set of engineering-oriented courses. Maybe:

\- estimation, planning, Gantt charts, scrum, Toyota production method, etc...
essentially project management with an emphasis on shipping

\- deterministic resource usage: manual memory management, correctness proofs,
big-O, etc

\- performance instrumentation, including conversion, business model, and
usability measurement

\- error/bug tracking and resolution, including monitoring, ship/don’t ship
decisions based on error rates, deliberate tracking of technical debt

Those are off the top of my head. I guess that’s just another random list of
professional coder topics to care about. But I think it should be focused on
cultivating deterministic outcomes, if we’re going to call it engineering.

And really, if we’re going to call it engineering, the set of practices need
to be tested scientifically to show that they work.

... which makes me want to go read academic Software Engineering publications
and are if any professors out there have already done just that.

------
cryptos
UML is not as useful in pracitice as I had thought as student. Especially use
case diagrams are more or less useless. Class diagrams are sometimes useful to
get some overview. However class diagrams for design patterns are often harder
to understand than the related code. The most useful UML diagramms are
sequence diagrams and activity diagrams, I think. It can be really useful to
illustrate complex flows. I think UML is mostly useful to illustrate small
parts of a system and not as an overall design instrument (model driven
architecture (MDA) in extreme cases).

~~~
krageon
UML, like most other tools, is pretty useful in moderation. It's not a
solution to every problem, but for a lot of situations where you have a big
project it can help to have a little overview of the process. From my
experience, I'm inclined to agree with your conclusion about the most useful
bits. At the same time, I don't agree at all that good diagrams should only be
used for small parts of your project.

Unless we're talking hobby projects, in which case anything goes.

