Follow Slashdot stories on Twitter


Forgot your password?
Programming IT Technology

Beginning Developers: Free Course from MIT 34

arrogance writes "Yes, this has been posted on /., and on Wired (five days after the /. story). But there are occasional postings on slashdot about Where to Start Learning to Program. There's a software engineering course at the MIT site that looks like it covers many of the basics of software development, from OO to testing to documentation. It also deals with a team based project end-to-end, which is a great way to learn, but it might be tough finding two or three like minded people to take the course with. Has anyone tried these courses? Are they any good? Have any slashdotters (is that a word?) taken the course "live"?"
This discussion has been archived. No new comments can be posted.

Beginning Developers: Free Course from MIT

Comments Filter:
  • not impressed (Score:5, Insightful)

    by jilles ( 20976 ) on Friday October 04, 2002 @02:44PM (#4388698) Homepage
    As a Ph. D. student in a software engineering research group, I'm somewhat knowledgeable about software engineering education. I must say I thought the course is a typical example of a course compiled by someone who has never been involved in a project larger than 'hello world'.

    The biggest misconception here is that software engineering somehow is about programming. In a large scale software project, the actual programming is only something like between 10% and 20% of the effort. The rest goes into negotiating requirements, design, testing, planning, dealing with the fact that there are multiple people involved (i.e. project managers, customers, designers, marketing, other programmers). Actually convincing students that this is true is a huge challenge, most won't find out until after they are working on large industrial projects.

    This course only prepares them for the 10-20% of coding. Like a good academic course it has a strong focus on designs (I have never seen a large industrial scale software project with up to date, detailed designs) and the actual programming concerns small toy programs. What it doesn't prepare them for is large scale software (>=100 KLOC) various development methods, various testing methods and their flaws, maintenance (very few projects actually start from scratch), projectmanagement, the fact that customer requirements will continue to change, internal and external conflicts about who does what and when, etc. Various very thick software engineering books exist (e.g. Sommerville or van Vliet), implementation is not the main focus in those books.

    "An introduction to OO modeling and programming" would be a more appropriate name for the course.

    A proper Software Engineering course involves letting large groups of students work on a medium sized project (for example provided by local software companies) and teaching them about the principles of software engineering (using e.g. the books mentioned earlier). Even that won't prepare them fully but at least they will experience strugling with deadlines, colleagues, changing requirements and interacting with customers. We have done just this in the past two years at the university of Groningen in the Netherlands.
    • Re:not impressed (Score:1, Interesting)

      by Anonymous Coward
      You're absolutely wrong.
      As someone who took the course, I can tell you at least 3/4 of the time was spent in things other than coding.
      Documenting, Design, etc.
      At the end of the course there is a "large software project" that takes about a month to complete and fairly accurately simulates working in a company type atmosphere.
      The course is definitely not all about coding.
    • KLOC fuzzy (Score:3, Insightful)

      by Tablizer ( 95088 )
      What it doesn't prepare them for is large scale software (>=100 KLOC)

      IMO, the "size of the application" is a rather *fuzzy* concept in a good many places. Where one "application ends and another starts" is often hard to tell.

      Perhaps if your shop builds big giant EXE's for whatever purpose, then such is more clear cut. But if one is using interpreters or web apps, then there is no one single glob to measure.

      Often there are many smaller "applications" (loosely used here) that all tie into the same central database. Do you count each little application, or is anything that uses that databases counted together?

      If the first, then I would note that the size of the "app" stays relatively consistent regardless of the size of the database. The average might increase in size a bit because the schema grows more complex, but it is at a pace slower than the DB size in most cases.
      • I know size is a relative meaning. KLOC is the best measure there is, unfortunately. Anything else quickly gets domain/technique specific. However, what I'm trying to point out is that most systems you are likely to encounter during your study are small systems that can be constructed by one or two programmers in a matter of days or weeks at most.

        In real life you encounter systems that take months or even years to complete by larger groups of people (I've seen cases where 300 people were working on a system for four years before the first release). University does not prepare studens for that kind of scale. Software engineering is about letting methods and techniques scale to build large systems in a predictable, controllable way.
  • by Gerry Gleason ( 609985 ) <gerry.geraldgleason@com> on Friday October 04, 2002 @02:53PM (#4388778)
    When I took it, the language was CLU, which is closer to Java than anything I have seen before or since. It seemed much easier to grok than Java, but maybe this was because I was young and my brain still somewhat empty.

    Actually, it was a new course and a new degree requirement when I returned to MIT after two years working full time. My advisor thought it would be good for me to take it even though technically it wasn't a requirement for me.

    My actual advice to people who think they might benefit from working through this course online is to go work on an open source project that interests you. The reason is that all the important stuff in software engineering is related to "programmin in the large". If all your experience when you hit the job market is from coursework, you've probably never seen a problem with more that a few hundred or thousand lines of code. That's just the point at which this stuff starts to matter.

    Because I had worked for two years, I had a much better appreciation than my classmates of what was important. I wish I knew that before taking the course because the lab course I really wanted to take was Doc Edgerton's strobe lab.

  • by devphil ( 51341 ) on Friday October 04, 2002 @03:02PM (#4388865) Homepage
    it covers many of the basics of software development, from OO to testing to documentation.

    While I'm overjoyed to see that documentation is something that's being taught as a basic fact of development, not something tacked on in the third year as an afterthought, I'm stunned that people (whether MIT or the article submitter) think of OO as a entry-level concept to be taught to beginners.

    Yes, OO is a great tool. Yes, so are most of the others. The right thing for the right job. But surely there are other concepts to be introduced first?

    • In spite of the comment you quote, this is not an intro course. It is a lab course that usually isn't taken until the third of forth year. The studend should know something about OO by the time they get there.
    • black art? (Score:2, Insightful)

      by Tablizer ( 95088 )
      Yes, OO is a great tool. Yes, so are most of the others. The right thing for the right job. But surely there are other concepts to be introduced first?

      Regarding "right tool for the job". One thing that I cannot get a consistent answer from OO fans (I don't like OO) is when to use OO and when to NOT use OO.

      Of course extreme OO zealots are going to say "always". But the more pragmatic lot agree that OO is not always the best solution. But there is very little agreement on when this is the case. They often say, "You just have to get a feel for when and when not", as if there is *no* pattern to when not to that can be written on paper.

      I find this odd.

      Determining the "best tool" for the job is very dark art. Until they solve this, they should call themselves "software artisons" and NOT "software engineers" (SE). There is too much subjectivity, or at least lack of articulation floating around out there among SE celebrities.

      (OO skepticism:
    • Yes, there most certainly are other concepts to be introduced first. []
  • Eh... (Score:4, Interesting)

    by rixstep ( 611236 ) on Friday October 04, 2002 @03:52PM (#4389319) Homepage
    - Required reading is a book on Java. To me, this is a helluva way to teach programming to beginners. They don't learn anything about the machines they're dealing with - and as a result, you're going to get more of the bloated and bugged output you have today.

    I don't give a royal hoot about objects - not where beginners are concerned. How about register shifts, how about how an accumulator works, how about some frikkin assembler?

    These people are being taught to fly and they can't even crawl. Major disaster.
    • I think we had this argument before. IMO it probably would not have affected my development style much if I never had exposure to assembler and lower level stuff.

      The only exception perhaps is internal data representation of strings, numbers, and the like. But beyond data, assembly and machine code training did almost nothing for me.

      If I went into assembler or tight embedded stuff or stuff in need of high optimization, it would perhaps made a difference, but I don't think it does when using 3rd+ generation langs and tools.

      I wish instead I was taught more formal set theory and relational theory. But, they did not have that then.
  • by Wonko42 ( 29194 )
    That girl in the photo is really cute. And she's wearing glasses!
  • I Had Daniel Jackson (Score:1, Informative)

    by Anonymous Coward
    After working on a small government radar tracking project, I had a grad-level class with Prof. Daniel Jackson on Software Design. Unfortunately, I'm not academically brilliant, because it usually took me an hour of stewing on a knot in my stomach before I figured out why it was there. So, I always ended up questioning decisions after they had been made. With MIT's liberal drop policy, I dropped the course nearly at the end, but here was my general experience.

    1) We were "improving" a NASA app that was having scalability problems

    2) No one had even benchmarked the application to see what the bottleneck was. I didn't even know how to bring the app up.

    3) The course was primarily for his graduate researchers so that they could get credit for their work and he was expecting near-full-time work from everyone. They obviously were spending a lot of time on it and discussing it outside of class, thus the others in the class were pretty well out of the loop.

    4) I got the feeling that there was no real engineering going on. It was purely mathematical and analytical (i.e. let's do this in my new modeling language). (At least there wasn't any going on during classtime).

    So, when the course was over, I had the general feeling that my 2.5 years of full-time experience being on a 12 man team creating an object-oriented radar tracking app from the ground up (including having a nearly identical performance problem!) didn't amount to a hill of beans because I couldn't express it in the right "terms" and didn't have an IQ of 250.

    I'm not saying I was perfect in this. Just that you don't ignore someone with that much domain expertise.

You are in a maze of little twisting passages, all different.