In my experience, university students spend years writing throw away code. They develop assignments, get them auto-marked, then move on.
On the other hand, professional developers are plagued by the long term consequences of their work and those before them. These subtle flaws only emerge over time.
How could a semester long programming course put students through a more realistic development cycle?
I'm not so sure what you're talking about is a great idea.
Students should be writing a lot of throwaway code, especially at the beginning of their education. They should be learning, writing code to test what they learned, and then moving on to the next thing.
Part of being a student is writing code that, 6 months from now, will look like garabge to them. "Why would I have done it this way?" This is a completely normal thing that everybody feels, and it's a sign that they're learning and improving as developers. But it also means that students shouldn't spend a lot of time polishing their code. Instead, move on to the next thing.
The rest of it comes with experience. Don't worry about "design" so much, and just focus on writing code that works. Forcing students to work with code they wrote weeks or months ago is just punishing them for learning and improving.
One sort of meta approach is to not try doing this within the context of a university course at all.
Instead, try and build up a culture where students are heavily encouraged (or even required!) to do internships and such (or at least join a research lab), perhaps over their summer. You can do this by having a strong career fair, by explicitly working in lessons or running workshops to prepare students for tech interviews, and so forth.
Basically, I feel one of the best ways to learn about the importance of software engineering and design is to actually work on a long-running project where you need to deal with the consequences of design decisions other people made. It's hard to engineer that kind of scenario in a classroom setting, so might as well off-source it (and simultaneously help students develop their resume as a bonus).
The disadvantages are that your students won't necessarily learn these lessons consistently, not all of your students will be prepared enough to pass a tech interview and get an internship (though I suppose it's good that they're learning this now rather then later), and that doing this will require a strong departmental push over a period of several years which will likely be harder to do compared to revamping a single course.
Being a recent grad who had a class where this happened, let me share my experience and answer your question.
The Worst Class of My Life
I had a class in which one quarter was devoted to a long-term programming assignment building on itself. We were given a partially implemented "Programming Language" based on python, but written in C++. We would have weekly tasks to add functionality to the language in the C++ code, so that we could build the "language" compiler and run test input through it. In theory it was exactly the kind of project I wanted, each component built on the one before it, but where it failed was the professor.
In practice, what happened was that the assignment wasn't very clear for the first week, there was no online resource, because we were implementing a made-up language, and the professor was at a loss to understand why we were all confused. When week 2 rolled around we all tried to build on code that already didn't work. So we had to try and fix part 1 then move to part 2. Over half the class bombed the first two parts, so the professor eventually had to give us the expected implementations of part 1 & 2 so that we could even do part 3 of the assignment. Utter disaster. Sure, I learned that building on top of bad code is bad, but at the cost of my grade and my sanity. I didn't like that teacher much.
However
However, that isn't to deter you from trying such a project. I think if good practices were followed, some sort of project like this would be cool, and very applicable to the real world, both at work and in the job hunt. My advice would be to monitor closely what the project is. Make sure it is a project your students are comfortable, rather than throwing a big project as a wrapper on already difficult course work. Make sure you have a good back-up plan in place if they fail early. Will you give them code? My advice would be to make the project independent of specific topics they need to learn and grade based on time spent working on the code and trying to make something usable. Try and have them use a versioning tool, so that you can see their commit record (My professors had us use github for our final projects in a few classes and for my capstone), that way, even if their program doesn't work, you can see the code and the thought process that went into working on it.
Basically, the project will depend greatly on the teacher assigning it. If there is good support and well thought out work, then it should be successful.
When showing pupils example code, include code which includes some bad habits: Poor names of methods, and variables; Poor indenting; etc.
Then have them read the code, and produce a short summary, of what the code does. Do this in an environment where they can not run the code.
Also include a few errors that will stop the code from working, get the pupils to find the errors and correct them.
Do this with two pieces of code, one well written, one not. Afterwards get the pupils to explain which piece of code was harder to work with, and why.
This is a little disconnected from your objectives. So later, when grading their work, link it back to this exercise. Remind them how they felt when they had to work with your bad code. Ask them how they think you feel having to read theirs. Ask them how they will feel in a few weeks if they read it.
Have them explain their code to you, two weeks after handing it in and moving on.
I think this is pretty hard to do in a single term and I don't think it is possible early in the curriculum. However, a two term sequence, even if not consecutive, might work out. However, I'm not sure exactly what you mean by "design" here. But here are some possibilities.
One design for such a course pairing is to have students do the design of some project in one term and then swap designs for implementation in the subsequent term. These can be team or individual projects, and part of the evaluation done by each team is to discuss the quality of the design they were asked to build. This assumes a stable student population, of course, to be really valuable.
However you need to have a fair grading plan for this to work. Students struggling to build a poor design shouldn't be penalized for decisions made earlier by others. Even when students build their own designs, it should be possible to recover from earlier mistakes. Don't let early errors put students on a path to doom.
It may be possible to shorten the whole thing to two half-terms, but I doubt that enough could be done to really let the flaws be exposed in such a short time. Bugs, like other things, need a gestation period.
I think that it is a mistake to try to do this early in the curriculum because the students already have enough to do and this might get in the way and leave them discouraged. Esteem building is good to do early. Reality training cam come after a period of "seasoning".
