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?

  • $\begingroup$ Give them some code with corrective/evolutive maintenance tasks. Good code and bad code, so they'll see the difference. (Ask professional developpers for samples of bad code :-)) $\endgroup$ – Michel Billaud Sep 11 '17 at 12:07
  • $\begingroup$ The obvious answer would be giving them a project or letting assignments use code from previous assignments. Ideally, the next assignment would require some non-trivial abstraction in the previous one. Is there a reason why you don't want these assignment dependencies or a project? $\endgroup$ – user24 Sep 11 '17 at 12:16
  • $\begingroup$ It would be better to identify the problem you're trying to solve. Commercial code needs to be nearly good enough, and not late enough to notice - quite reliably. $\endgroup$ – Sean Houlihane Sep 11 '17 at 12:26
  • $\begingroup$ @SeanHoulihane did you say, “nearly good enough”. This is by definition not true. It needs to be at least “just about good enough”. However if you increase, internal, quality then you can do it cheaper and quicker. (increasing external quality will increase costs, unless done as a side effect of increasing internal quality.) $\endgroup$ – ctrl-alt-delor Sep 11 '17 at 13:39

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.

  • 2
    $\begingroup$ Very much this. Deep perspective comes from deep experience, and that is simply not a goal that coursework should be expected to encompass. I do not run a trade school, and I have other, more pressing concerns than poorly mimicking the experiences of someone who has been a developer for 10+ years. $\endgroup$ – Ben I. Sep 11 '17 at 17:39

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, 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.

  • $\begingroup$ Interesting. Thanks for sharing. I've been a student in a course with cumulative assignments. The lecturer offered the choice between building on your own code, or taking code supplied by the lecturer at each stage. I always opted to use the supplied code, as did most other students. Perhaps compounding problems from old code is just a headache students don't need. My intention is to have students reflect on their code and learn, not just throw it away. However, I don't want them to stress out and lose marks for their mistakes. So perhaps simple code reviews offer a good middle ground. $\endgroup$ – user2923 Sep 13 '17 at 1:09

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.

Connecting this to their own code

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.

  1. If you are a believer in separating design from implementation in a traditional way, then a design course followed by an implementation course might work for you. A language principles course, for example, might have elements of design followed by a compiler building course. Other sorts of projects might work as well.

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.

  1. If you are willing to drop the word "design" from the question, however, the possibilities expand. "How can we show students the consequences of their early decisions?" This is amenable to any sort of development process, including agile, in which design and development are done by the same people and iteratively. Here the suggestion of user @Keelan can be easily applied. But not likely in a single term. If one course has students building tools of some kind and a later course has the students using those tools themselves, they will learn about earlier bad decisions, either of design or implementation. But, again, make sure the students have a path to success even if they have made early mistakes.

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".

  • $\begingroup$ Writing software is design; copying a file to a hard-disk or CD is software manufacture. See also lean manufacture: not being repeatable, that is not doing it exactly the same way every time is wast. In writing software it is the other way around, because we don't manufacture software, we design it. The same is true of all design: If you do the same design again it is waist. Just reuse the old one. $\endgroup$ – ctrl-alt-delor Sep 11 '17 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy