New Masters Program in Software Engineering


  • I survived the hour long Uno hand

    In my Master's, I had a course called Software Engineering and Architecture (or something along those lines). The first half of the class was okay, but the second half literally got hijacked by "Now the industry says we're not supplying enough .NET developers so here's a manual on how to do ASP.NET, here's what your final assignment looks like, don't ask me any questions because I barely know .NET myself." Don't do that.

    I do feel that how to architect maintainable software is a crucial skill that many of my coworkers seem to lack. Testability is another good thing to learn, particularly with the DevOps movement blurring the lines between coders and testers. But the practicalities of where do you put what kinds of code, SRP, designing a good API, general organization... these are crucial skills that most people seem to learn the hard way and could easily be taught in school.



  • @boomzilla said:

    I like hg for this application, because in a way it sits in between svn and git. ...The downside to svn is that you have to have a server, even if it's only local.
    (1) Yeah; I'm a Git user and prefer it, but the difference is minor and there are reasons to go the other way too. (2) Svn supports file:// URLs, so no, you don't need a server (if by "server" you mean "makes stuff available over the network, even if just to localhost), you just need two directories.


  • ♿ (Parody)

    @EvanED said:

    Svn supports file:// URLs, so no, you don't need a server (if by "server" you mean "makes stuff available over the network, even if just to localhost), you just need two directories.

    Yes, I was counting that as a server.


  • Discourse touched me in a no-no place

    @tarunik said:

    Port C# to my STM32F051, then.

    How about an STM32F2?



  • @Yamikuronue said:

    "Now the industry says we're not supplying enough .NET developers so here's a manual on how to do ASP.NET, here's what your final assignment looks like, don't ask me any questions because I barely know .NET myself."

    That's funny, when I was last dealing with such coursework (over a decade ago), the faculty were crazy for Unixes. We had to do our work ssh'd on a Solaris cluster, and the professors were continually bashing Windows ("Want to join the virus of the month club? Use Windows! Doesn't happen on Unix!").



  • @accalia said:

    design patterns. Not just what they are but why they are. what is the factory pattern, what problem is it built to solve and when should it be employed. I see to many people that over architect to the moon and back because they are cargo culting design patterns not understanding the why.

    This a thousand times.



  • @Groaner said:

    We had to do our work ssh'd on a Solaris cluster, and the professors were continually bashing Windows ("Want to join the virus of the month club? Use Windows! Doesn't happen on Unix!").

    To be fair a decade ago there was some truth to it.


  • Discourse touched me in a no-no place

    @accalia said:

    design patterns. Not just what they are but why they are. what is the factory pattern, what problem is it built to solve and when should it be employed. I see to many people that over architect to the moon and back because they are cargo culting design patterns not understanding the why.

    The most important parts of a design pattern are the forces that drive you to using it, the consequences of using it, and the reasons for not using it. One of the most important things to learn is what to not do, how to be discriminating among the squillions of different possibilities, which is indeed all part of the why. (And if you don't include Composition and Delegation among the taught patterns, you're doing them a vast disservice.)


  • Discourse touched me in a no-no place

    @Mikael_Svahnberg said:

    I am in the process of starting up a new master's education in a software engineering topic. Are there any topics we should definitely teach that would make our students more employable? Are there any values (for example a craving for learning, as you pointed out) that we should focus on instilling, or are there any particular ways of working that would make them more employable?

    Back when I used to do some teaching, one of the exercises that we set them was an evil one. They had to pick a topic from a small list (though one of the items on the list said that they could do other things relevant to the rest of the course if they cleared it with us first) and then write some code (almost invariably a ZIP or tar.gz, though the instructions were not specific) and a report on the code (most used Word but I was really flexible there) as part of a small team (typically 3–4 people). Three of the assessment criteria, all of which were explicitly mentioned to the students, were “demonstration of teamwork”, “use of relevant tools, libraries and/or frameworks” and “insight into the problem”. They had 2–3 weeks to work on it, with a final stop date actually caused by the need for the students to prepare for other exams (but we set it as a hard deadline for all of them).

    I've been told by students who took the course that it was an evil exercise, but good and useful. It certainly allowed students to show just how good they actually were, and was actually pretty easy to assess. (It wasn't their main project for the year.) The standard tended to be quite variable, but it allowed a lot of room for them to show just how good or bad they were. The best? We tried to encourage them to do a PhD with us, or we'd even once or twice outright make a job offer. 😃


  • FoxDev

    @dkf said:

    The most important parts of a design pattern are the forces that drive you to using it, the consequences of using it, and the reasons for not using it. One of the most important things to learn is what to not do, how to be discriminating among the squillions of different possibilities, which is indeed all part of the why. (And if you don't include Composition and Delegation among the taught patterns, you're doing them a vast disservice.)

    EXACTLY MY POINT!
    :-D



  • @Mikael_Svahnberg said:

    "If you keep your project files on your networked user account (J:) Visual Studio will be too slow to use, so copy your project to C:/TEMP, and don't forget to copy it back once you are done"

    That was the way I was taught C at undergraduate level.
    [size=10](Except for the Visual Studio part. There was no IDE either, just a text editor with syntax highlighting and a command-line compiler. Also TMP was on a ramdisk so if you forgot or there was a power cut you were screwed.)[/size]

    I hated that workflow and didn't know why - it wasn't until starting actual work that I was finally introduced to source control as a concept.

    IMHO, any school at any level (from primary school on up) that doesn't include source control in their programming and computing classes is deliberately abusing their students.

    Interesting, the discoeditor preview ate the first line of my reply. I wonder if it'll post correctly.
    [Edit] No, it did not. ] newline text newline [ eats the text.



  • Teach estimation. Very few programmers know how to give a good estimate or even whether they have enough information to be estimating rather than guessing.



  • The problem I run into on estimation, is I walked into a place and I've been asked to estimate some work, usually with a cms or project I have never worked with before and even when communicating I don't know because of too many unknowns I am usually pressured into giving a number ... So you are in this situation where you new and don't have the confidence to tell them it is unrealistic.



  • Perhaps they just want a Fermi estimate?



  • Nope



  • @accalia said:

    documentation, and not just how to make UML diagrams (although they should be able to produce those too)

    OK, noob question from someone with no actual experience developing. What is UML typically used for, in real life?

    Because the only thing I've used it for was representing domain models, you know, "a company wants to keep track of their employees and projects, employees can be managers or subordinates, projects must have at least one manager, blah blah blah draw the class diagram" (that was an entire course. 3 months doing that), and later use case diagrams. But I assume they are used for more than that.



  • @anonymous234 said:

    What is UML typically used for, in real life?

    It isn't


  • FoxDev

    @anonymous234 said:

    What is UML typically used for, in real life?

    to satisfy micromanagers mostly (to judge by my work experience.)

    it's also used to chart out dependencies in packages, or program flow, or several other things that are useful to look at from a debugging/documentation perspective. but that doesn't account for the amount of the stuff that is produced by some offices.


  • Fake News

    @anonymous234 said:

    What is UML typically used for, in real life?

    While the authors of the UML spec tend to believe you can model Life, the Universe and Everything using UML, in effect it's more like "our diagram conventions are more important than your diagram conventions". If you can explain a problem in your own terms you certainly do so, if you happen to need a diagram you can use UML conventions instead of making up your own and then having to explain them.

    If no UML diagram seems an immediate fit, wing it and invent your own. If you have to explain again why you chose a particular obscure UML diagram, it defeats the advantage of not having to explain anything.



  • You learn all the fancy diagrams so that you know which to discard when you do your design on the back of a napkin.

    Using UML as a teaching method is, imho, jus a means so that the students learn one way of going from requirements to code in a traceable way, and more importantly learn to recognise the qualities that makes a "good" design.

    Other than that, the best use of UML is to keep a lot of computer science researchers out of harms way.



  • I see. So diagrams can be useful, but it's silly to have to diagram everything using some specific rules.


  • FoxDev

    exactly!



  • @Mikael_Svahnberg said:

    Using UML as a teaching method is, imho, jus a means so that the students learn one way of going from requirements to code in a traceable way

    This is more imporant than it sounds. I have two problem with most programmers I work with.

    First, they don't design from requirements. They say they do, but there is no path from requirements to design - which they just pull out of their ass or do it the way another project did it.

    Second, almost no one I have worked with can defend a design. They can rarely answer questions like "What alternatives did you consider" or "Why is this better than <<some alternative>>". Most people seem to stop thinking once they get to a design that works. Unfortunately; Classic ASP, web apps with a back end in Fortran, and ColdFusion are all examples of platforms that "work". Working is not good enough - students need to know how to distinguish between a good design that works and a bad design that works. They also need to be able to express what they want out of the next generation of technology, or they will simply be following fads for the rest of their career.


  • ♿ (Parody)

    @anonymous234 said:

    What is UML typically used for, in real life?

    Satisfying delivery requirements created by a contracting officer who doesn't realize what a waste of time it is.


  • ♿ (Parody)

    Oh, UML also used to be good for selling Visio licences.


  • Discourse touched me in a no-no place

    Still is. That's really the only reason most people in my team have a Visio license.


  • Discourse touched me in a no-no place

    @anonymous234 said:

    What is UML typically used for, in real life?

    Not much. If you've got a complex protocol involving many different actors, you might use a sequence diagram to explain what's going on. But on the whole, at that point you'd be better off scrapping the protocol and using something simpler where the amount that most agents have to know about the others is more strictly limited.

    Class diagrams, the poster child of UML, are at best useless. They don't scale to real programs at all, not even close.

    Overall, the biggest problem of UML is that its style of visual programming (for that's what it is, even at high level) doesn't scale well at all. The key problem is that it's not good at showing partial views except in cases where it's being used to describe what's going on without being connected to anything real; it takes human brainpower to partition the space of entities into things that belong in a particular diagram and things that don't. They make reasonable teaching tools I suppose (e.g., for helping to describe some types of software pattern) but they simply aren't a substitute for a programming language.

    Even visual programming languages are better at complexity management than UML. (Or they're toys.)


    It can be considered that there is a language (of sorts) behind UML: it's MOF, and you really don't want to know more. It exists to make you know less than you did before…



  • Damn, a search of UML MOF and after reading the wikipedia and the OMG entries, all I felt was happiness for not having touched any of that in my career. Also, and as you said, I got absolutely nothing out of this.



  • @lightsoff said:

    There was no IDE either, just a text editor with syntax highlighting

    You had syntax highlighting? We had to make do with ed on a hard-copy terminal. Both ways. In the snow. Get off my lawn.


  • Grade A Premium Asshole

    Pffffbt, I am just surprised you did not have to punch cards with a piece of flint that you knapped yourself.



  • My first two programming classes at community college (FORTRAN IV and some long-forgotten mainframe assembly) did use punch cards, but I thought this made for a funnier joke. When I first went to university, they did still have a few old card punches around, but I never used them nor saw anyone else use them.



  • You sound like someone who might have some good stories of the old days. Might as well put your writer hat and share some.



  • @dkf said:

    Class diagrams, the poster child of UML, are at best useless. They don't scale to real programs at all, not even close.

    If I am trying to work out the relationships between classes in a module or small system I find it helpful to write down something similar to UML or ERD to help me understand how to break down the relationships on a piece of paper that I will never refer to again.


  • Discourse touched me in a no-no place

    @lucas said:

    a piece of paper that I will never refer to again

    Whiteboards work pretty well too. Our coffee area at work is surrounded with them.


  • ♿ (Parody)

    @Eldelshell said:

    UML MOF

    Could be worse. DoDAF:

    This shit is UML after one of the world's biggest bureaucracies got done with it.


  • ♿ (Parody)

    @boomzilla said:

    DoDAF

    Oh, and to be clear, they use this shit for everything. Or they used to a decade ago. It's possible they've moved on to something worse by now.

    So, like, there are series of diagrams for the "architecture" of, "How do we bomb people?" And lots of less interesting things, too.



  • @boomzilla said:

    DoDAF

    It contains DoD. WTF is a certainty.


  • Grade A Premium Asshole

    @dkf said:

    Whiteboards work pretty well too. Our coffee area at work is surrounded with them.

    One of our former clients was a software vendor that had painted entire walls with whiteboard paint. As you walked to the offices of the developers, there was a wall that had your to-do list, two walls in their rec room were whiteboard paint, etc. Pretty nifty idea really.



  • @Polygeekery said:

    Pffffbt, I am just surprised you did not have to punch cards with a piece of flint that you knapped yourself.

    That's the way my mother learned to program.
    Also she had to post the cards away to the mainframe and get the answers back a few days later.

    As a child I used to draw on her thesis programs with crayons. Presumably she thought that was all they were good for by then.


  • FoxDev

    i was trying to resist, but you forced my paws:



  • @accalia said:

    i was trying to resist, but you forced my paws:
    FTFY, surely.


  • FoxDev

    pull request accepted.

    ;-P



  • I was expecting this one


  • FoxDev

    too predictable.

    :-P


  • Discourse touched me in a no-no place

    FWIW, the one we have on the wall at work is this:



  • @Jaime said:

    Teach estimation. Very few programmers know how to give a good estimate or even whether they have enough information to be estimating rather than guessing.

    Sadly, KCS complexity theory has a thing or two to say about the notion of estimating how long writing a piece of software will take...

    TL;DR for the paper: "Estimating how long a software project will take will always be the land of semi-wild-arse-guesses, because an estimation algorithm for any given accuracy bound will have a strong lower bound on complexity near the complexity of the project it's trying to pull together estimates for..."

    @anonymous234 said:

    What is UML typically used for, in real life?

    The place I interned at used it to communicate object relationships, much like an ERD in OO clothes. Sadly, it's too complicated for its true home: the nearest whiteboard!

    @dkf said:

    Not much. If you've got a complex protocol involving many different actors, you might use a sequence diagram to explain what's going on. But on the whole, at that point you'd be better off scrapping the protocol and using something simpler where the amount that most agents have to know about the others is more strictly limited.

    Class diagrams, the poster child of UML, are at best useless. They don't scale to real programs at all, not even close.

    Overall, the biggest problem of UML is that its style of visual programming (for that's what it is, even at high level) doesn't scale well at all. The key problem is that it's not good at showing partial views except in cases where it's being used to describe what's going on without being connected to anything real; it takes human brainpower to partition the space of entities into things that belong in a particular diagram and things that don't. They make reasonable teaching tools I suppose (e.g., for helping to describe some types of software pattern) but they simply aren't a substitute for a programming language.

    Even visual programming languages are better at complexity management than UML. (Or they're toys.)


    QFT and +1, well put. Diagram notation should serve the purpose, and UML gets that bass-ackwards (see for instance the UML statechart notation, which is pretty ridiculous).


  • Discourse touched me in a no-no place

    @tarunik said:

    Diagram notation should serve the purpose, and UML gets that bass-ackwards (see for instance the UML statechart notation, which is pretty ridiculous).

    The best uses I've seen of UML have been in books on patterns, where they helped a lot in explaining what was going on. But pedagogic teaching tools aren't (necessarily) software engineering tools.


  • Discourse touched me in a no-no place

    @Polygeekery said:

    I am just surprised you did not have to punch cards with a piece of flint that you knapped yourself.

    We would have LOVED to have knapped flint. We had to use snakes. If you were lucky, you'd get one that wasn't venomous. Most times, your snake had two fangs, which limited the range of patterns you could punch on tape.



  • @Polygeekery said:

    One of our former clients was a software vendor that had painted entire walls with whiteboard paint. As you walked to the offices of the developers, there was a wall that had your to-do list, two walls in their rec room were whiteboard paint, etc. Pretty nifty idea really.

    We have that. Open office floor, conference rooms/etc in the middle. All walls are whiteboard paint. (and evidently we have some very artistic people) I was told that the paint is almost (or is, forget) more expensive than a whiteboard of the same size.

    Noisiest, most distracting environment I've ever worked in...



  • @FrostCat said:

    We would have LOVED to have knapped flint. We had to use snakes. If you were lucky, you'd get one that wasn't venomous. Most times, your snake had two fangs, which limited the range of patterns you could punch on tape.

    We just shoved one fang into someone we didn't like and twisted. 2 problems solved!


Log in to reply