Agility for students, revisited

Since writing about teaching agility to computer science students, I’ve had a few more ideas, plus excellent suggestions from Patrick Linskey and Michael McCracken.

Patrick’s suggestion (which I can’t believe I didn’t think of myself) is to teach them more about the history of our field. We don’t have to make computer science students scholars of computer history, but we should give them some idea of the rich scope of the topic. Introductory computer courses tend to cover Babbage, Turing, and von Neumann, and then skip straight to Bill Gates. And for most CS students, that’s the end of it.

Michael’s suggestion is this:

… professors often understand the distinction between teaching skills for their own sake and teaching them as applications of more general principles. It’s important to convey that to the students as well. Giving an idea of trends and perspective helps breed the kind of healthy skepticism about tools and paradigms that Glenn mentions.That’s absolutely right. All too frequently I meet young programmers who are confused about thatthey think the particular techniques and tools they were taught are the fundamental things.

Here are the other things I’ve thought of:

  • Computer science students should learn, even as undergraduates, to read technical papers, and how to find them. (I have suggestions for anyone who’s looking for seminal papers that are well written and approachable.)
  • Along the same lines as Patrick’s suggestion: teach them about the great personalities of the field. Knuth, Hoare, Dijkstra, Englebart, Kay, Moore, Cray, Cocke, Hopper, Dahl, Thompson, Ritchie, Kernighan, McIlroy, Bentley, McCarthy, Minsky, Wirth, Steele, and many, many others are important not just for their technical contributions, but also for the color and vibrance they’ve brought to our field and its history. Learning about them and their relationships helps bring our past and present to life.
  • Help students to understand that there are communities of developers that they will be joining, and that those communities are where much of the advancement comes from. User groups, mailing lists, wikis, and blogspace are just some examples. Show students how they can be contributors, not just users.
  • Somewhere, years ago, I heard that one of the characteristics of “the professions” (medicine, law, architecture, engineering, etc.) was that professionals were expected to keep their education current. I have some friends who are doctors, and their homes and offices are always full of current medical journals. I often hear people complain that as a field we are not more “professional,” and yet few programmers take that responsibility seriously. It’s amazing how many programmers with years of experience have never read a book about programming (as opposed to just an API reference or tutorial) since they left school. That ethic of continued self-education should be taught to CS students, if they are to call themselves professionals.
  • Students need to leave school with some knowledge of ideas that are out of the mainstream. ZUIs, magic lenses, pie menus. Plan 9, BeOS. AOP, intentional programming, multiparadigm programming. Mob software. And many, many more.

I think I’ve worked there!

Saturday at the Atlanta Java Software Symposium, I overheard this as I walked past a small group talking in the hall:

“Our architecture is Big Ball of Mud, and we use Bitter Java as our coding standard.”

But the guy talking didn’t look familiar. He must’ve started working there after I left. :-)

Further evaluation of Objective-C

I am learning to be very fond of Cocoa, and Objective-C has been fun to program in, at least for the small things I’ve done so far. But I’m still trying to decide how to develop the personal project I’ve written about in previous entries, and for that purpose I’m noticing some weaknesses that Objective-C has, at least as compared to Java. (It certainly has strengths relative to Java, too. But I already knew about those. I’m just realizing the weaknesses now.)

The large amount of metadata that is stored in Java bytecode files is a huge advantage for Java. One of the things that annoys me about Objective-C is the fact that a class definition is split between a header (interface) file and an implementation file. My assumption is that header files are necessary because the object files don’t have sufficient metadata; you need the header in order to compile code that uses the class. But this solution is less than ideal. It forces a lot of duplication of information (method signatures, for example). And one of the terrific things about Java is that you can use any third-party libraries you have access to, even if you only have the object code. (Documentation is helpful, of course, but frequently not necessary, and the class files contain all the information that the compiler needs.)

Memory management in Objective-C is much better and easier than C or C++, and it does have a few advantages over Java. But overall, I’ve concluded that the Java mechanism is much better for application robustness. It’s certainly easier to program with.

Finally: Objective-C, by including all of C as a subset, suffers from C’s lack of rigor and discipline at the level of the type system. That is, the Objective-C type system can always be subverted by C code. Why is this important? Apart from the obvious safety and robustness issues, there’s another point that I’ve just become aware of. I’ve just been playing with IntelliJ IDEA as a development environment, and I’ve been very impressed by its thorough and easy refactoring support. Not only does nothing like that exist (so far as I know) for Objective-C, I believe it would be very difficult—if not impossibleto do a similarly thorough job for Objective-C.

I may well be wrong, and I’d be delighted to be wrong. But for the moment, I’m leaning strongly toward buying an IDEA license and developing my application in Java.

Cocoa preferences

One of the nicest things about Cocoa is the user preferences architecture. It provides a nice way to store explicit user preferences, as well as implicit things like window placement. And what I discovered today is that Cocoa has very nice hooks to make that easy. For example, to make a window remember its last position, you just have to add one line to the awakeFromNib method:

[self setWindowFrameAutosaveName: @"LinkWindow"];

It’s so simple that there’s no reason not to do it. It took just a couple of minutes to add that to Blapp.

Agility for students

Last night I gave a talk on Extreme Programming and the principles of agile development to the Fort Worth IEEE/CS. It went very wellthe attendance was good, there was a lot of interest, and there were many good questions at the end. I was filling in for Dave Thomas, who couldn’t make it due to a death in the family, so I was very glad it went so well. (I didn’t want them to be disappointed with the second-stringer!)

The first question after I concluded was from a TCU Computer Science professor who said, “As an academic, what can I do to prepare my students for environments like this?” My first answer was, “Can we have lunch? Because the answer to your question is long.” But then I gave her a short answer: teach your students not just to write code, but to read it, and read code written by other people, and then to add features to it to test whether they’ve understood it. She seemed happy with that (I gather she’s already doing a lot of that, as well). But there is more to it than that. Here are some things I’ve thought of:

  • Teach the students the principles of emergent behavior, so they’ll be comfortable with the ideas of evolutionary design.
  • Teach them about refactoring and the ways in which software is malleable. Teach them how this can be used as a feedback mechanism to incorporate what you learn into the design.
  • Teach them the history of engineering, and encourage discussion about where software development currently sits on the path to maturity that the other engineering disciplines have gone through.
  • Discuss the ways in which software development is similar to other engineering disciplines, and how it differs. Likewise, discuss similarities with art, craft, and science.
  • Teach them skepticism about tools, and explain how the state of the software development art (in terms of platforms, techniques, and paradigms) always runs slightly ahead of tool support, so those who aren’t dependent on fancy tools have an advantage.
  • Teach students that we don’t really understand software development that well, and the techniques they are learning today aren’t necessarily the best way to do things.
  • You won’t have time to teach them everything about computer science, but at least give them glimpses of the many things they don’t know.

If anybody has any more ideas, please let me know. (Also let me know if you disagree with any of the ones I listed.) She’s hip, she gets it, and we certainly need computer science professors who genuinely want to know the answer to the question she asked. I want to give her great answers.

subscribe via RSS or JSON Feed