Teaching Java and OOP

I'm starting this topic to try to get a discussion going with a recently-joined forum member who's from the academe.

Campbell and I have made a few comments recently about what we see as a shortcoming in the way students are being taught programming and Java these days. We have seen a number of students who said that they have completed at least one course in Java programming but are still woefully in the dark about basic language and programming concepts. My son, who is now taking his second Java programming course at a large university in the US MidWest, is in the same boat in terms of the instruction he's receiving although I don't think he's quite as lost as some of the students we've seen here lately.

Campbell and I think that starting students off with largely procedural style programming exercises and then trying to add objects later is ineffective, confusing, and possibly even detrimental. We think that it's entirely possible to teach proper object thinking and OOP programming in Java from the start and still make it very accessible to beginners.

I'm inviting newcomer Paul West and perhaps some of his colleagues to join this discussion.

In another thread, Paul West wrote:... They have just been introduced to objects--they still get classes and objects confused!

One reason I like JavaFX is that it does have some web-dev features in it (FXML), but the main issue is the support may be dwindling.  On the other hand, Swing has so many resources and legacy applications.

IMO, if they are still getting classes and objects confused, then trying to teach them technologies like Swing and JavaFX will only add to that confusion. At most, console input/output would be more appropriate and would allow you and the students to focus more on the more important concepts of object-orientation, program organization and factoring/refactoring, and clarity.

Here's one example of a student who has one prior Java programming class under his belt: https://coderanch.com/t/670267/java/java/Tips-improvement

IMO, this student is far from where he should be in terms of learning progress. After a semester of Java programming instructions, he should at least have a handle on all the basic program and control structures like if-then-else, while-loop, for-loop, methods, etc. Spending the better part of an entire semester on for-loops is ridiculous! Granted, this may be an extreme example but other students we've seen around here (and from what I've seen in my son's course syllabus) don't seem to be faring much better.

I'm basing my judgement on my own experience from way back in the late 1980s, in the Philippines! The first programming class I took as an engineering student was Pascal programming. Our first machine problem was to generate the Fibonacci series to the Nth number. I think our second machine problem was to calculate factorial(N) iteratively. Then recursively. Somehow, most of us were still able to complete those programs. I should note that although that was my first programming course, it was the second for many of my classmates who had taken the course on BASIC programming in the previous semester.

I realize there might also be a natural bias in the samplings we're seeing here at the Ranch since it's unlikely that we'll see as many of the students who are not as lost as the ones who show up here. Still, in my conversations with my son about his classes, I get as sense that there are still a good number of students who are essentially getting left behind.

I'm about to go to class, but what problems are you seeing?  At my University, the base classes go Procedural Programming (C)-> OOP (JAVA) -> Data Structures(C++), which is (probably) common.  In my OOP class, I focus on how OOP helps working in groups (visibility, code reuse, interfaces.)  If Procedural wasn't first, I'd be focusing more on control structures, primitive types, functions, etc before going on to Objects...

Paul West wrote:At my University, the base classes go Procedural Programming (C)-> OOP (JAVA) -> Data Structures(C++), which is (probably) common.

For me, the progression was Procedural Programming (Pascal) then Data Structures & Algorithms (Pascal) I && II. OOP wasn't included in the curriculum in my time although there were courses on AI, Prolog, and LISP for higher years.

I think the main problem for students who start off with Java as their first programming language is that they lack context in procedural programming. When I started learning Java, I could compare it to what I know from languages like C, BASIC, and Pascal. I also had the advantage of having worked with Delphi/Object Pascal. I guess you could say that I had a bit of an advantage over these kids in terms of learning Java and OOP. The difference, I think, is context. I could put "object-thinking" in context and could see the differences and advantages that OOP brought to the table. Most of these kids don't have that and being thrown into a mixed paradigm of writing procedural code in a supposedly object-oriented language like Java causes a lot of confusion.

Paul West wrote:One reason I like JavaFX is that it does have some web-dev features in it (FXML)

I agree with Junilu. It isn't worth going through JavaFX in my opinion as there is nothing special about it, especially FXML. It follows MVC architecture and the magic story ends here. Even Oracle encourages to use Scene Builder along with FXML for auto code generation, so that simplifies and speeds up things even more. There should be a course about Web Authoring which supposed to teach about web-dev features, but that is not much to do with Java programming language concepts as such.

I too believe that time spent on JavaFX better would be spent for a deeper grasp of main language concepts. The main program's logic in JavaFX application going to be in a model and might controller parts where again we go back to concepts Junilu have mentioned. So, to go with GUI before good grasp of objects is putting a cart in front of horse.

But if the choice needs to be made, I'd go with pure JavaFX (without FXML) which is close to Swing and after all it is current Oracle GUI building standard.

Regarding procedural vs. object-oriented programming in Java, I recognize there's a balance that you need to strike here. On the one hand, most people seem to find procedural programming easier to understand because most people are used to thinking about instructions that way, as a series of steps that you follow. That's probably why most beginners will write programs that have all their code jammed into a humungous main() method. Teaching if-then-else before for-loops and while-loops seems to take the natural tendency to think sequentially into consideration. Start off with a conditional execution, then a binary branch, then an iterative control structure. Then you introduce methods.

I wonder if that's not like dropping people blindfolded into the forest and telling them to find their way out. The similarity is that in both situations, the subject or "victim" if you will, has no context. They don't have a point of reference from which to plan their way forward and out of the situation they find themselves in.

If, on the other hand, you showed them the lay of the land first, so that they can get a sense of the big picture and where they are headed, that might give them a better chance of navigating through the thick underbrush.

I'll try to give an example later.

I do not think Java is a good first programming language.  OOP is not intuitive until foundational programming syntax/semantics are established (control flow, data types, algebra, function, etc...)  Now, if you have a way to establish those concepts while thinking OOP, I'm open, but the idea of grouping data types and functions together is not intuitive if you don't know what those are.

One of the big reasons to start off thinking of programs as step-by-step is that what the programs are (until we go to multi-processing.)  I see it as important to help build up the intuition before moving on to advance features (OOP.)

In other words, I think Procedural should be taught before OOP as it lays down the groundwork before proceeding to code organization, design, etc...

As for JavaFX vs Swing.  Let me point out that I do one week of GUIs.  Everything else I test their classes (usually via JUnit.)

Paul West wrote:I do not think Java is a good first programming language.  OOP is not intuitive until foundational programming syntax/semantics are established (control flow, data types, algebra, function, etc...)
...
In other words, I think Procedural should be taught before OOP as it lays down the groundwork before proceeding to code organization, design, etc...

In many schools, like my son's, that's a moot point. Java is the first programming language many academic programs have in their curriculum. Also, there are many self-taught programmers who, for some reason or another, want to start out with Java. Most of the books and training material available out there pretty much take the same approach though. Again, I have to go back to finding a way to give the learner more context. Most of the first lessons dive right into details, without so much as a mention of the bigger picture.

Here's an outline that I'm toying around with:

1. Programming as problem solving
2. Stating the problem
3. Envisioning the desired end state
4. Identifying main steps for solving the problem
5. Decomposition - breaking things down into smaller tasks
6. Putting everything together
7. Using tests to drive the problem solving process

This can probably be shortened to just items 1, 2, 3, and 4 to start with. Then as the problems become more complicated and solutions more involved, you can add on decomposition, orchestration, and testing. Somewhere in there, you can show the difference between procedural thinking and object thinking.  I have to go now but I can share a couple of examples I'm playing around with later this evening.

Paul West wrote:. . .  OOP is not intuitive until foundational programming syntax/semantics are established . . .

I think the real problem is that OOP is not intuitive full stop. We see lots of people here writing pure procedural code, and they have completely failed to add objects to that. If it is so easy to add objects after teaching selection and iteration (which are intuitive), why don't we see people writing good OO code here?
I was taught Java® differently. We started with objects; they were simple, but didn't involve selection or iteration. Only after we had seen objects did we see if or while.

What I'm missing sofar: what kind of students are we talking about?

Campbell Ritchie wrote:If it is so easy to add objects after teaching selection and iteration (which are intuitive), why don't we see people writing good OO code here?

I think that expecting students to write good OO code is a tall order. I’m sure some exceptional ones can but not many. I think that understanding programming syntax, control flow, data types etc is easier than understanding OO concepts. Many students leave university with a rudimentary understanding of what objects are and how they communicate with each other. It takes a while to fully understand this. It takes even longer to learn how to write good OO code as this requires a reasonably good grasp of OO principles (like SOLID) and design patterns which some seasoned programmers struggle with. I've been programming for a year and a half and it took me a while to fully grasp basic concepts of OO programming like encapsulation, inheritance and polymorphism. In university, you learn enough about these OO concepts to pass an exam but I think that a student needs real world experience in order to fully grasp these OO concepts.

Ah, I was using intuitive to mean understanding not easy.  So, I was saying the intuition helps give you an understanding (reason) for something, not that it will come easily.  This is especially true for OOP which is easy to poorly engineer.  Most students understand the desire for objects after data types and functions have been taught.  This is a bottom up approach, and it sounds like you are advocating a top down.  Since I'm a systems programmer, I'm not surprised, but I'm interested as to why top-down is preferred/better here.

Now if the issue on this site is that students start with Java as their first programming language and work on procedural coding, then yes that is absolutely terrible.

To expand on Daniel's point of a BS in CS student's grasp of OOD, keep in mind that we aim to create generalists who can pick up on topics easily.  I'm not saying a student shouldn't know the basics (encapsulation, polymorphism via inheritance, separation of labor, etc..), but that trade-offs are made.  Example: Do you we teach advance Design Patterns or Caches?  Furthermore, all the Universities I've attended as a student and faculty have CS as a packed major.  In other words, we do not have enough time to cover everything.  American Universities have time constraints.

For my OOP class I've been slowly adding Design Patterns and other OO principles.  It would be great if there was a good list of questions about OOD.  Most I find are: write a class that does blah blah blah.  Instead, I'd prefer, Design a system that does blah blah adhering to <insert Desin Pattern/Paradigm here>.  The questions should have a grading rubric that helps me identify good student solutions and bad because there will be so many of each.

I'm a big fan of refactoring to patterns instead of starting off with a pattern in mind. I'm also a big fan of simplicity, hence, I often make references to the 4 Rules of Simple Design. Patterns evolved out of instances. Someone had a problem, they solved it a certain way. Someone else had a similar problem, and they came up with a similar solution. After a third time, somebody said, "Hey, there's a common theme here..." and then the pattern was given a name, defined, and publicized. It seems logical to me to have students go through that same process of discovery and recognition, rather than telling them, here's what you want to do, and this is the pattern that you want to use to do it.  That gives them only the end goal and the solution, leaving out the most important thing, IMO, about patterns: the context in which a problem can be solved by applying a pattern. And I don't buy an argument that says, "Well, the problem is 'How do we achieve this goal?'" It's not, and if you think it is, then I don't think you understand enough about patterns.

In studying/teaching the proper use of patterns, I would give some seed code that has the characteristics of the problem to which a particular pattern is best suited.  Maybe the exercises can be modified to "Here's some code. Here's what we want to do. These are the problems with this code. Does pattern X or pattern Y apply here and how can we refactor this code so that the design is improved by applying one of these patterns?"

I have started recommending to participants of the TDD workshop that I give at work to start getting better at refactoring before they start trying to write tests first. To get better at refactoring, they need to get better at recognizing code smells. To get better at recognizing code smells, they need to recognize when principles have been violated, and to that, they need to understand principles. So for me, it all boils down to knowing principles first. Everything else follows from there. In this progression, I think learning about patterns would be somewhere around when you start learning to get better recognizing code smells and refactoring.

I promised an example so here's what I'd do to give beginners an idea of the difference between procedural and object-oriented code:


By introducing students to the concept of giving objects the responsibility of performing tasks in the program early on, I think this allows them to form a good mental model with which they can take on the of encapsulation and inheritance. I think the first concept that needs to be understood before all that though is that of "assignment of responsibility" - which is related to functional decomposition, and you can easily make contrasts between procedural style Java and object-style Java to show that.

Then you can introduce examples where data is involved, like say introduce a message variable that can change values, then require that the program be able to display greetings in various languages. Then add more twists to the requirements to build on top of what's already been written.  Each progression would show how the program can be written procedurally and then contrasted with code that uses objects. This at least gives them some context and a way to better see the point of using object-orientation. With these simple examples you can already show decomposition, abstraction, good naming, and organization of the code.

Junilu Lacar wrote:I'm a big fan of refactoring to patterns instead of starting off with a pattern in mind. I'm also a big fan of simplicity, hence, I often make references to the 4 Rules of Simple Design. Patterns evolved out of instances. Someone had a problem, they solved it a certain way. Someone else had a similar problem, and they came up with a similar solution. After a third time, somebody said, "Hey, there's a common theme here..." and then the pattern was given a name, defined, and publicized. It seems logical to me to have students go through that same process of discovery and recognition, rather than telling them, here's what you want to do, and this is the pattern that you want to use to do it.  That gives them only the end goal and the solution, leaving out the most important thing, IMO, about patterns: the context in which a problem can be solved by applying a pattern. And I don't buy an argument that says, "Well, the problem is 'How do we achieve this goal?'" It's not, and if you think it is, then I don't think you understand enough about patterns.

I looked at the TOC for Refactoring to Patterns and it looked good, so I requested my free exam copy -- a perk of academia.  I have considered using Design Patterns as my book, but that is a little advance for the students.

I think a little history will help people understand my position right now.  When I started at the University, the course order was [Alice or VB] -> C++ -> Java I -> Data Structures (C++).  In other words, it was very language focused, which I wanted to change.  I put in a request to change Intro to Computer Science to Procedural Programming and Java I to Object Oriented Programming.  Last week that got approved, so I'm in this transition period were the course is still "Java I", but I'm focusing more on OOP.  Right now, I'm trying to figure out the best way to setup the new course as all the old materials are heavily Java focused.  The current book is Java Foundations: Introduction to Program Design and Data Structures which does have some OOP, but focuses on Data Structures--an important subject covered in the next course.  If you have suggestions, please send along!

I get the feeling most people here would agree the change is for the better, although some would want to change the order.  BTW, Alice/VB courses are for people with no programming experience who want to get an idea of programming.  So, while Java/OOP is technically the third course, I generally say it is the second programming course.  (If you have ever done Alice before you will see why.)

Your example is a good start, especially for getting terminology down (which is hard at first.)  I just need a good source that can continue it throughout the course.  Aka, a textbook...

Piet Souris wrote:What I'm missing sofar: what kind of students are we talking about?

These are college students in their second or third semester of Computer Science at an accredited 4-year private University.  They have gone through a basic Procedural Programming course (no Objects) so they understand basic data types, control structures, functions, and divide-n-conquer.  Most are Computer Science majors, but some are minoring.  Most that minor are in Graphic Design.

Most students (majors and minors) are taking a networking class along with this one.

Two other books I'd recommend are Clean Code and Agile Software Development - Principles, Patterns, and Practices both by Robert Martin. I'd say the PPP book would be useful not so much for its discussion of Agile software development but for the discussions about design principles (SOLID) and patterns. I was very happy to learn that my son's current course also uses Effective Java by Joshua Bloch as a reference, so I gladly let him borrow my copy of the book.

I would love to see collaborative development (working either in pairs or groups of 3 or 4) be encouraged more, at least when working on course projects. Being familiar with pair or mob programming would really prepare your students for the kind of real-world development done at leading tech companies these days.

I received the Refactoring to Patterns book and I do like it, but I think it is too high level for the beginning of the OOP course.  Right now students need to understand OOP/OOD basics.  Afterwards, later in the course, I believe some of the ideas from Refactoring to Patterns would be very helpful--thanks!  

I looked around and got a hold of "The Object-Oriented Thought Process" (TOOTP), and I'm liking it so far (haven't finished reading it yet.)  My main concern is the focus on theory instead of practice--the students need lots of concrete examples.  The TOOTP book provides some good examples, but I believe they need more of how to write the Java syntax (the book does not cover Java syntax extensively.)  In other words, I believe the students would get the semantics, but be lost on the syntax (a common problem in my courses.)  I'm debating on letting them "use the Internet" or sticking with a second book to fill in the need.  Do you have any suggestions, the search has become extremely monotonous...

Currently I'm looking at http://www.tutorialspoint.com/java/java_tutorial.pdf and have requested a copy of "Core Java Volume I--Fundamentals" to fill in the practical need.

Thanks again for all the help,

~Paul

Paul West wrote:. . . "The Object-Oriented Thought Process" (TOOTP) . . .

Is this that book? I have an earlier edition and I wasn't particularly taken by it, though other people liked the newer edition more. See our books pages. I agree that books about refactoring are a long way beyond the reach of the students we are discussing here.

There is one thing from the Refactoring to Patterns book that I think any programmer at any level of skill can learn and appreciate, and that's the Composed Method Refactoring. It is one of the three refactoring techniques I emphasize to everyone I mentor. The other two are Rename for clarity and Extract to eliminate duplication. If we teach everyone to ALWAYS look for an opportunity to do these three refactorings AT LEAST every two minutes as they write code, more people would learn to get into the proper mindset about coding, design, and quality.

Here's another problem that I see in many of the problems that students post here:  They are given step-by-step instructions on HOW to build a program but they don't seem to understand the WHY or WHAT they're doing. Here are just a couple of examples (read the instructions the students were given carefully):

https://coderanch.com/t/671520/java/Java-Inheritance-Error
https://coderanch.com/t/671579/java/returning-String-representation-Ball-Path

I walked my son through a full solution (about 50 lines of code) of that ball drop simulation problem and it took less than 20 minutes for him to fully comprehend what he would need to do.  In those 20 minutes, I demonstrated the importance of choosing good names, showed him how to refactor (rename) to clarify intent, showed him how to organize the code and how to refactor (extract) to eliminate duplication as well as clarify intent, showed him a better way to generate a random boolean value using java.util.Random.nextBoolean() instead of Math.random(). More importantly, I walked him through the thought process I used to attack the problem and come up with the solution.  All this will give the student the context that they will very rarely, if ever, discover themselves if left alone with just step-by-step instructions.  They also lose the opportunity to think about good names, semantics, and organization when they are given detailed instructions like what to name a class.  In the case of the ball drop simulation, I don't even agree with the requirement to call the class "Path" -- I used "Ball" instead in my solution and it reads a lot better and makes a lot more sense.

As Andy Hunt said, "Always consider context" and I think that's what a lot of instructors don't give to their students enough.

Another thing that bothers me is that there seems to be a general perception that refactoring is too advanced a concept for beginners. I just don't see how hard it can be for a beginner to understand the benefit of doing something like this:

It takes only a few minutes to explain the thought process and motivation behind the refactoring here. With just a few minutes of investment, the student gains a valuable tool that he/she can use in similar situations in the future.

Hi Junilu,

Refactoring is not too advance for my class.  What I stated was that the book Refactoring to Patterns would be too much of a jump to use solely for my class.  The issue I'm having is finding a good book to bridge from I-have-no-idea-what-an-object-is-and-I'm-a-terrible-coder to refactoring.  From your example, I'm always amazed how confusing "private boolean bouncesRight()" is to my students...  Private!?  Boolean!? rand.something!?  You would be amazed how many times I see students type Random.nextInt() and they look at me like it should work perfectly! >.<

I know how some other Java classes are taught which lead to a lot of How and leave out Why/What.  Please understand that my students seem to grasp Why/What fairly well.  I have finished grading the midterm and they did well (80%+) on the SOLID portion which required them to read code, identify why the code was poor (smells) and then stub out a solution.  What they did less well on was following the iterations of a for loop.  Yes, literally they knew how to apply LSP, but failed on how many iterations are in a simple two variable for loop.  (!!!)

~Paul

Paul, thanks for sharing. Just to be clear, those comments I made were general and not in any way directed at you specifically.  And yes, most of Refactoring to Patterns would be a bit much for beginners except for the one part about Compose Method. I really think the compose method refactoring example given in the book illustrates very important concepts that need to be introduced as early as possible.

I agree with you on the Compose method--it is a simple (beginner) process to improve readability with minimal overhead.

Speaking of unbelievable things...  You wouldn't believe the looks of enlightenment and wonder you can get when you walk people through steps for doing the refactoring of that Compose Method example.  I've seen programmers I mentor struggle for a few minutes to find a name that approaches the expressiveness and succinctness of atCapacity() - I've only ever had one person out of dozens whom I have mentored who came up with that exact name within seconds of talking through what the intent of the formula was.  When they finally figure out a good name, you can literally see that look of recognition spread across their faces. That's very rewarding.

Another one is when you explain the arrow code anti-pattern to them. I've seen experienced programmers get very sheepish when I point out the problem in that example. I get a lot of "Huh, I never knew this was a bad practice" admissions of guilt and even once had a group tell me "Huh, and all this time, we thought that nesting was a good thing. We do that a lot."

Junilu Lacar wrote:Another thing that bothers me is that there seems to be a general perception that refactoring is too advanced a concept for beginners. I just don't see how hard it can be for a beginner to understand the benefit of doing something like this:
[code]

// Initial code

if (Math.random() < 0.5) {
   return "R"
} else {
   return "L"
}

// First refactoring: use java.util.Random instead

I guess it is pretty much subjective. This method is so easy to read, that I certainly would not refactor it. I would change the '0.5' for a parameter 'p' though, to enable to solve the assignment even when the nails were biased in the way the ball would bounce. Or I would have this method return a 1 or a 0, with some extra function f: int -> string. Having such a method allows one to easily adjust the solution when the assignment would have  been about drawing red and green balls with substitution,  given some ratio for these balls. The real context being that the assignment is just a demo of that well known toy about the binomial distribution, and maybe the deeper problem is simply some lack of decent maths. Would the student be able to reckognise how to answer a question like: what is the chance the ball ends up in some specific bin?

Piet, you miss the point. It has nothing to do with that specific example. My point is that any discussion about refactoring, even just rename or extract or compose method seems to be generally passed up as being too "advanced" for beginners. I assert that there are refactorings that can and should be taught very early on and students should be challenged to think about things like clarity of intent, organization, eliminating duplication, and simplicity as early as possible in the learning path.

I have volunteered to be a mentor in the upcoming HackOHI/O event at Ohio State University on November 19/20. Hopefully, I'll get a chance to talk to some of the CSE/CIS faculty & staff who will also be onsite to advise and judge the participants. Best case scenario, I get a collaboration started between industry professionals and colleagues in academe to see what can be done to better align what students are being taught with what we in the industry would like to see them being taught that would be useful in giving them a running start when they enter the workforce as software/IT professionals. Wish me luck.

I shall be very interested to hear what comes out of those discussions.

I finally got a chance to talk to some folks on the faculty and I got a name of someone who can hook me up with people I can talk to about starting up a conversation around this. I guess that's as good as a first step as I could hope for. The person I talked to did say that she has heard the same kind of comment about a misalignment of instruction and industry expectations so at least they know there's a fairly common concern that needs to be addressed somehow.

The story will continue...

After several weeks and emails, I'm at the point where I'm hopeful that I can have an actual conversation with some folks from the faculty of the CSE department at the university. The lady I've been in touch with who's serving as a liaison says that the faculty are discussing my emails and how they want to approach this conversation.  In the meantime, I'd like to prepare a document to summarize the issues I think need to be addressed.

I definitely want to put something in that document about the lack of context given to students. We see numerous examples here where students are given lots of details but have very little idea of what the big picture is that all these little nuts and bolts fit into. That is, there seems to be a disproportionate focus on mechanics and technical details (like the obscure Design-By-Contract notation that I discussed in another thread) and less on principles and foundational skills like problem solving approaches, organization, clarity, abstraction, functional decomposition, etc.

Are there other things anyone can suggest that would go into a document that lists the "Top 5 Concerns about the Misalignment Between Industry and Academia"?

Regarding the lack of context, an analogy I was thinking of making was, as cheesy as this may sound, from the "Karate Kid".  I don't believe you can just tell kids to keep practicing wax-on and wax-off and then expect them to be able to connect that to parry in / parry out. Some kids, the talented ones who will figure it out anyway, may discover the connection between the motions they are going through in their homework, labs, and projects and real-world or even theoretical applications but I think a larger population of students will just be lost and utterly confused. More can be done to help these kids make the connection. Does that make sense?

That makes sense, and I agree that there is a severe lack of context for students here.  A root cause is that students haven't had to deal with working in the field.  My current solution is to have them do a group project, plead with them to do proper requirements, design, testing, and coding style.  After they don't, watch the ship sink, then have the "coming to Jesus" moment after their presentation.  While this trial by fire method takes the entire semester, I've had good feedback afterwards (although the students despise it during the semester.)  Some of the things they seem to learn:  students realize how to deal with slackers, why you need to test your interfaces thoroughly, why simple interfaces are a good thing, why you should not mind asking others for help, and repositories are a good thing.

While I wish there was a simpler solution, I'm starting to believe that the students just need to go through the pain.

So a quick top 5 off the top of my head:
1) Team Experience (see above)
2) Abstraction: It takes students awhile to how simplify their thinking improves productivity.
3) Public/Contract: It takes students awhile to realize that anything will be sent to their public methods.  I make my test cases pure evil.  Public/Contract should be simple, yet powerful enough to fulfill the requirements.
4) Refactoring:  Most student seem to believe it is best to just rewrite the entire thing.  There are numerous was to refactor code.  Hopefully I'll have time this semester to go through them.
5) Testing: This goes with #3, but more of a your test cases are part of your code.  IE: we need to be able to measure the quality of your code as well as the code submitted.

Thanks Junilu on staying on this, I'm interested to see what come out!

Thanks, Paul.

I heard back from a faculty committee chair today. They seem willing to discuss my concerns but also asked me to cite "standard literature, e.g., well-cited papers in conferences devoted to CS education such as SIGCSE, that may be directly related to your suggestions." I just replied that I have no such references to give them since the concerns I have come mostly out of personal experience, and informal observations and discussions like this. I'll put my concerns and things we've discussed here in a writeup that summarizes what I want to address with them. Hopefully, I can make a compelling enough case to keep the conversation moving forward.

I was actually able to find some literature that I can cite. I did a search on research into misalignment of industry and academia in Computer Science instruction and found several articles. One article even summarizes the issue quite well: "However, the gap that exists between what is taught at school and the skills required to perform on a job is so wide that a high percentage of young graduates are said to be unemployable for lack of needed skills that would make them profitable for any employer."

We get a proportion of young undergraduates who scrape through whom we wouldn't call competent programmers anything. Maybe some of them shou‍ld have been steered into other careers. Maybe some would have made good plumbers and shou‍ld be going round behind sinks with a blowtorch and would be happier doing that. I don't know. I do know some people who are clueless get through final exams, and a 3rd class degree doesn't mean they are going to be any good at a programming job. Maybe they shou‍ld have failed. I don't know.

I think Campbell touches on a very good point.  There are students in my class that I know are not going to do well in the field.  Luckily, I teach at a private University so I am free to come up to the student and talk about how Computer Science *may* not be the right career path for them.  Also, I'm able to setup homework/tests to show students what they need to do in order to succeed in a Software Engineering career.

Unfortunately, I believe a good number of public college/university have a difficult time with dissuading students from certain career paths.  I have taught at a public college and I've talked to some professors from others.  There is a push to meet a graduation quota which essentially drives a "lower bar" for classes.  It also dissuades professors form have "the talk" as well.  This is coupled with the fact that the US is in short supply of programmers has only made the situation worse.

Sadly, I have no solution to this problem because there is so much money in the University system.  =(

Junilu -- So a University asked for academic papers showing why academia is disconnected from reality?  ba dum ching!  In seriousness, I'm glad someone has at least attempted to show the problem.