Real-World Software Development Course for University

Jeff Atwood recently wrote a blog entry saying the best (and maybe only) way to REALLY learn how to write software is to actually DO IT. Although I’m a great believer in learning by doing, Jeff’s post did get me thinking about how I would design a university course to help teach the things you learn “on the battlefield”.

Start - Students are divided up into groups of 3-4, given a loose specification and told to implement solution in technology X by date Y (12 weeks away). Students are given a “budget” of time that they need to spend on the project each week (say 4-6 hours per person) but their involvement in the project should stay capped at that 6 hours/week. Students would be required to keep a short diary of what they are spending their project time on.

1 week in – no changes. Any requirements clarification requests by students are answered vaguely.
2 weeks in – students are told they need to have a working prototype ready in 2 weeks.
3 weeks in – students are told they must use component Z that will be supplied to them to perform a certain thing. 1 major aspect of the system will be changed (for example “it has to work offline” if it is a web app, or some crazy security model that needs to be applied).
4 weeks in – prototypes are evaluated. Students are told to scrap prototype as second big functional change is introduced (“it has to be integrated into outlook”, or “it cannot use any client-side script”). Teams are re-organized.
5 weeks in – breaking change to API of component Z
6 weeks in – students are told the system must use data from a legacy system, which will be made available to them in coming weeks. A “representative sample” (laughs sadistically) will be provided to them (tell them in week 8). Representative sample is small, and structured in a very different way to the way the problem domain is currently understood.
7 weeks in – some requirements changes
8 weeks in – merge teams, tell them to “consolidate” code. More requirements changes. Another breaking change for component Z.
9 weeks in – More requirements changes, One team member is randomly chosen to be “team representative” and will be tasked on writing performance appraisals for other team members. Team members will be asked to rate each-other. Highest/lowest ranking member from each team (based on peer-peer ranking) will be swapped with another team.
10 weeks in – Legacy data is delivered. Some fundamental information is missing, and shows major discrepancy in way requirements are defined vs. data present to support requirements.
11 weeks in – minor but annoying change to the environment the software has to run on. Possibly some left-field performance requirements thrown in.
12 weeks in – project completion.
13 weeks in – students are asked to write up what challenges they faced on the project, the risks they faced and the lessons learned. Students could also optionally deliver the solution here if they have negotiated to do so.

At any time students could negotiate to deliver less, deliver later, or “spend” more resources (although they would not be explicitly told they could do so). Push-back on requirements changes and schedule re-negotiation (based on said changes) would also be allowed but also not explicitly stated. Although this sounds somewhat sadistic I think it would go some way to prepare students for “real-world” development. Each Student’s final mark would be based on the way their team’s degree of success delivering the negotiated features on time and on budget, and their write-up of the lessons learned.


You really need to add layoffs at week 8 and restaffing to build up the team at week 10.
5/04/2007 9:19:00 AM
Reg Braithwaite
This is almost exactly the degree I was imagining! Well done, very well done indeed…
5/04/2007 11:35:00 AM
Chris Austin-Lane
This sounds like that Paper Chase episode where the only way anyone could finish the assignment was to negotiate contracts between the various study groups. It was ostensibly an assignment about obscure legal precedents, but was really about contract law.

5/04/2007 12:28:00 PM
Is it ethical to throw false problems in the face of real programming? Natural problems crop up enough. Just have the students get a real client and problems will be as plentiful as worms after heavy rain.
5/04/2007 3:59:00 PM
I took that course! Only they called it a "job" and paid me for it. I so wish I had of taken Underwater Basket Weaving instead…
5/04/2007 7:14:00 PM
Brett Morgan
Oh how you hurt me…

In my experience CompSci students have enough trouble navigating a unambiguous spec…
5/04/2007 9:14:00 PM
We did do something a little similar at Imperial (University of London), but it wasn’t quite as sadistic as yours.
6/04/2007 2:55:00 AM
I’ve been told stories of a similar technique used in some design programs. Students get a nice tidy spec that they work on for an extended period, then a couple days before deadline they get an update: the "client" has changed his mind about requirements A and B.
6/04/2007 7:52:00 PM
Joseph Cooney
Thanks Reg (although after reading your post I don’t think you were paying me a compliment)
7/04/2007 3:10:00 AM
This kind of course structure is already in existence at the Rochester Institute of Technology’s Software Engineering department, which I’m a part of…the course wasn’t this crazy but it’s a good example of this kind of theory in practice.

Dept. Site:
Course Activity list:

I really like this blog…expect me to be around for a while. Software discussion + a WPF pro? Sounds perfect to me. :)
9/04/2007 4:31:00 PM
… Or the students could just (a) drop out, and get a real programming job; or, (b) enrol in a polytech ‘programming’ course. I see little value in wasting the time of the lecturers and students with these kinds of lessons. CompSci at uni should be teaching what cannot simply be learnt on the job - it should be pushing the boundaries of the art, and not just imitating what is already happening in the industry. </rant>
11/04/2007 4:28:00 AM