Putting the magic in the machine since 1980.

Saturday, April 17, 2010

What We Should Teach IT Students

Yesterday I attended POSSCON where I saw a talk by Andy Lester on "What We Should Teach IT Students". As the use of the word IT in the title reveals, the target audience for the talk was enterprise developers.

For readers new to the field, enterprise developer is just a type of job. The easiest way to define the term is by pointing out that Blue Cross Blue Shield and Bank of America hire "enterprise developers" while Google, Microsoft, and Valve hire "software engineers". That is, enterprise developers write the software that makes the business run smoothly—process insurance claims—while developers write the software that IS the business—the new version of Windows. From an accounting point of view, enterprise developers are often a cost center for the company while developers are a profit center.

Still, the recommendations are largely applicable to all. He recommends students learn:

  1. Source control
  2. Bug tracking
  3. Compiler (paying attention to the error messages)
  4. Make and the philosophy of repeatability
  5. Lint / splint or similar static code analyzers
  6. Serious editing
  7. DRY: Don't Repeat Yourself
  8. Defensive programming
  9. Maintenance: working on other people's code
  10. Manual testing
  11. Automated testing
  12. Efficiency and why it does not matter
  13. Thinking about the: business, project, release, deadline (getting the bigger picture)
  14. Teamwork: work well with others
Our curriculum covers all of these, some more than others, and I am in full agreement with all of them.

Some of these, however, I think must be left mostly to the student. I know that learning to use the editor is super important, but I don't think we need an actual class to teach editing! I really can't see myself standing in front of our students for a whole semester telling them "To compile your code, press F8; to indent your code press Ctrl-A then Crtl-I". They know they can just get the list of shortcuts and memorize the ones they need. Still, I do make a point in my classes to stop and explain how I got System.out.println to appear after just typing sysout. Similarly, learning to use a source control or bug tracking system is just not that hard (compared with, say, implementing a compiler). Overall, the students who have not learned to use their editor, or understand compiler errors, or DRY, are generally the few who really don't care about programming, and their grades show it.

Still, I agree that these are all important skills to have.

Andy also said all students should have read Code Complete, which is the required textbook for my 492 class. He also mentioned The Pragmatic Programmer which is also a personal favorite of mine and on my list of recommended books for 492. Of course, we all know they are good because stackoverflow says they are.

Monday, April 5, 2010

Multiagent Systems Introduction

Last week it was my pleasure to give an invited talk at Temple University, part of their Robert M. and Mary Haythornthwaite Foundation Distinguished Lecture Series. I tried to provide a high-level overview of multiagent systems is all about, which is always a huge challenge as the field covers a lot of disparate areas. After some thought, I decided to pick three applications and
  1. describe all the issues relevant to the problem,
  2. show how we use theory (either algorithms, game theory, or Economics) to get a better understanding of the underlying issues,
  3. explain how there is still much engineering that needs to be done because even the best theory or algorithm still millions of details, and software is just a collection of details.
For posterity sake, below are the slides I used. The slides contain as little text as possible, which I think generally makes for a better talk.