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
- 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.
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).
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.
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.