[ericHosick]

Just a story.

I was lecturing a class on UML and Design Patterns to students who had never coded before (basically UML).

The class textbook, lecture notes and lecture slides I was given had a lot of coding examples.

During the 12 week class, I wrote a book on Object Oriented Modeling (staying two chapters ahead for the students) that had almost no source code.

It was a challenge to explain OOM, UML and Design Patterns to students who had no prior coding experience.

I do feel it is totally possible to teach people how to "program" without knowing how to code.

[tsumnia]

It is possible with the help of flowcharts and pseudo-code; the issue I've run into many times is depending on the class, you'll lose student interest over not actually doing anything. If it is a matter of limited resources, ala no computers, then go for it, but looking back, I'd feel a little short-changed if I couldn't walk out of the class without a functional program, no matter how insignificant.

This is where I liked MIT's EdX course. Mostly Python interpreter, but around the end you were given a GUI simulation of controlling a Roomba. You wrote the Roomba's logic and then ran the simulation. You could walk away from the class and say 'Look at this... I built this'.

[ericHosick]

I do agree that there is really nothing to show that you've done: program wise. On the other hand, the students did learn a lot about critical thinking which, I feel, is a great start to programming.

This was also for a BIS degree (not a CS degree) which focused on the "business" side of information science: so most students weren't interested in coding (though I felt this was not to their advantage).

Really, it was a bit the fault of administration for placing the class in the first semester of the degree when students had not taken any programming classes yet.

[tsumnia]

I'm in the same boat, business side of IS, teaching Visual Basic.

If you don't mind me asking, what textbook did you use (or atleast company)? We use Cengage currently and I'm just appalled at some of the stuff I have to cover. I've been searching for a replacement.

[eru]

What's the point of learning UML and Design Patterns? (Especially, if you can't program?)

What were students supposed to be able to accomplish that they couldn't do before?

[ericHosick]

> What's the point of learning UML and Design Patterns? (Especially, if you can't program?)

It was for the BIS program (http://www.rmit.edu.au/programs/bp138). You can get an idea of the program for graduates.

I look at coding as a way of programming but not all programming needs to be done by writing code. There are other ways to program a computing device: a.k.a alter the behavior of a program.

> What were students supposed to be able to accomplish that they couldn't do before?

I don't recall the ILO's (Intended Learning Outcomes) of the class but I do recall one was being able to apply Design Patterns in their analysis and design.

I'm not saying I agree with people designing software systems without also having an ability to code but I do think people can think critically about solving problems using tools like UML without having to code out the solution.

[eru]

Thanks for taking my somewhat flippant questions seriously. Thinking about design seems useful.

Learning about the `classic' design patterns seems silly. They are basically workarounds for shortcomings of OOP. And if one can not program, one does not need to know about workarounds.

Did you include a study of the Mythical Man Month?

[ericHosick]

Design patterns are just that: common patterns that we see occurring within our designs. Just in case you don't know about it, the usage of Design Patterns within computer science were influenced by Christopher Alexander (http://en.wikipedia.org/wiki/Christopher_Alexander). See http://en.wikipedia.org/wiki/A_Pattern_Language.

Design patterns exist within all programming methodologies including functional programming, structured programming, etc. In some cases, the pattern is incorporated within the methodology, some within a specific language, some are incorporated within the framework and others are used at the domain level.

Just because a design pattern has become so ubiquitous we don't even know we are using it doesn't mean the pattern does not exist. The iterator pattern has been weaved into languages for both functional and object oriented programming. Java has implemented it at the framework level. Maybe it should not have been done there.

In all cases, this really has nothing to do with shortcoming of OOP (or any programming methodology for that matter). It has to do with allowing us to recognize common patterns of design within software.

> Did you include a study of the Mythical Man Month?

Yes. But not in the above described BIS class. It was in another class in the CIS program.

[eru]

Oh, yes, lower-case design patterns are fine. I was just frustrated with the Design Patterns (in capitals) movement.

By the way, mutable state is also a design pattern. But it's sort-of invisible in Java.

[pdenya]

> I do feel it is totally possible to teach people how to "program" without knowing how to code.

What is the benefit here compared to learning programming by coding?

[ericHosick]

In my opinion, writing software requires two "primary" skills.

A) A student needs to be able to map real world systems to a computing device. This requires a lot of critical thinking and is basically the process of automating a real world problem.

B) A student needs to be able to code out the problems they have solved above.

Where it gets difficult is that students are usually taught how to code before they are taught how to do that mapping from the real world "thinking" to computer world "thinking". I feel their internal model of programming becomes tainted with concepts like scope, functions, methods, parameters, pointers, lists, arrays, data structures, inheritance, composition and so on. All useful tools, but hard to mentally picture without understanding why the exist.

I look at learning to code before learning to critically solve problems like learning all about a motorcycle without understanding it's purpose: to move you from one location to another. Sometimes, students have ah-ha moments and they would be like "Oh, now I see why we are learning about motorcycles. It is because we've learned about these roads things and we can use the motorcycles to move us from here to there using these road things we learned in a prior chapter".

Where it gets even more difficult is that students are often expected to learn how to think critically to do that mapping thing (A) and at the same time learn to code (B).

In my opinion, the optimal way to learn how to program would be to teach the critical thinking aspects and associated tools in A and then teach implementation (programming) in B (then alternate) with about a two week gap. One class on A, then two weeks later a class on B, then two weeks later a class on A.

This is an iterative approach to learning that allows students to master concepts in software development and then apply those new skill by programming (by coding or other means) solutions in a computing device.