Authenticity and Challenge: Software Engineering Projects Where Failure is an OptionPosted: October 17, 2012 Filed under: Education | Tags: authenticity, collaboration, community, curriculum, design, education, educational problem, fred brooks, Generation Why, higher education, in the student's head, learning, principles of design, reflection, resources, sigcse, software engineering, student perspective, teaching, teaching approaches, thinking, tools, universal principles of design 2 Comments
It’s nearly the end of semester and that means that a lot of projects are coming to fruition – or, in a few cases, are still on fire as people run around desperately trying to put them out. I wrote a while about seeing Fred Brooks at a conference (SIGCSE) and his keynote on building student projects that work. The first four of his eleven basic guidelines were:
- Have real projects for real clients.
- Groups of 3-5.
- Have lots of project choices
- Groups must be allowed to fail.
We’ve done this for some time in our fourth year Software Engineering option but, as part of a “Dammit, we’re Computer Science, people should be coming to ask about getting CS projects done” initiative, we’ve now changed our third year SE Group Project offering from a parallel version of an existing project to real projects for real clients, although I must confess that I have acted as a proxy in some of them. However, the client need is real, the brief is real, there are a lot of projects on the go and the projects are so large and complex that:
- Failure is an option.
- Groups have to work out which part they will be able to achieve in the 12 weeks that they have.
For the most part, this approach has been a resounding success. The groups have developed their team maturity faster, they have delivered useful and evolving prototypes, they have started to develop entire tool suites and solve quite complex side problems because they’ve run across areas that no-one else is working in and, most of all, the pride that they are taking in their work is evident. We have lit the blue touch paper and some of these students are skyrocketing upwards. However, let me not lose sight of one our biggest objectives, that we be confident that these students will be able to work with clients. In the vast majority of cases, I am very happy to say that I am confident that these students can make a useful, practical and informed contribution to a software engineering project – and they still have another year of projects and development to go.
The freedom that comes with being open with a client about the possibility of failure cannot be overvalued. This gives both you and the client a clear understanding of what is involved- we do not need to shield the students, nor does the client have to worry about how their satisfaction with software will influence things. We scaffold carefully but we have to allow for the full range of outcomes. We, of course, expect the vast majority of projects to succeed but this experience will not be authentic unless we start to pull away the scaffolding over time and see how the students stand by themselves. We are not, by any stretch, leaving these students in the wilderness. I’m fulfilling several roles here: proxying for some clients, sharing systems knowledge, giving advice, mentoring and, every so often, giving a well-needed hairy eyeball to a bad idea or practice. There is also the main project manager and supervisor who is working a very busy week to keep track of all of these groups and provide all of what I am and much, much more. But, despite this, sometimes we just have to leave the students to themselves and it will, almost always, dawn on them that problem solving requires them to solve the problem.
I’m really pleased to see this actually working because it started as a brainstorm of my “Why aren’t we being asked to get involved in more local software projects” question and bouncing it off the main project supervisor, who was desperate for more authentic and diverse software projects. Here is a distillation of our experience so far:
- The students are taking more ownership of the projects.
- The students are producing a lot of high quality work, using aggressive prototyping and regular consultation, staged across the whole development time.
- The students are responsive and open to criticism.
- The students have a better understanding of Software Engineering as a discipline and a practice.
- The students are proud of what they have achieved.
None of this should come as much of a surprise but, in a 25,000+ person University, there are a lot of little software projects on the 3-person team 12 month scale, which are perfect for two half-year project slots because students have to design for the whole and then decide which parts to implement. We hope to give these projects back to them (or similar groups) for further development in the future because that is the way of many, many software engineers: the completion, extension and refactoring of other people’s codebases. (Something most students don’t realise is that it only takes a very short time for a codebase you knew like the back of your hand to resemble the product of alien invaders.)
I am quietly confident, and hopeful, that this bodes well for our Software Engineers and that we still start to seem them all closely bunched towards the high achieving side of the spectrum in terms of their ability to practice. We’re planning to keep running this in the future because the early results have been so promising. I suppose the only problem now is that I have to go and find a huge number of new projects for people to start on for 2013.
As problems go, I can certainly live with that one!
If the project fails, does that mean the students fail the subject? Running a unit like that seems problematic. If not, how do you assess each student in this case?
Also, how do you prepare the clients for the danger that they will have nothing usable at the end? I always work hard when negotiating a student project with any external client, to make sure they don’t depend on the outcome.
If the client doesn’t get working software then, while we’ve failed to deliver software, it doesn’t necessarily mean that the students themselves will fail. Have they done sufficient work on the design, production and documentation of the course, yet not been able to deliver final working software as per spec? There’s still a (large) amount of room for them to pass although their final mark will not, of course, be as high as if they achieved more.
To prepare the clients, we discuss it up front – are you prepared for the possibility that we won’t have the software ready at this time point? We then look carefully at the requirements to help the students work out what they can achieve in the time frame and make sure that they have the best chance of producing a workable outcome, which may be the whole thing or a solid subset. Yes, we also spend time with the client to work out what can and can’t be achieved but we always want to have room for very high achievement.
We meet with the students very regularly to make sure that the team is working, individual contributions are meeting expectation and that progress is actually being made. Normally, the client meetings focus on a series of developing prototypes, which are an easy way to get client feedback and show progress to everyone. The meetings, the client interactions, the code base, the documentation and our observations of the process all go together to give a final mark.
We run a system where it is possible for a group project to succeed, yet a student who has chosen to do nothing can still legitimately and defensibly fail because of their lack of contribution. This does take a lot of work on our part but the students definitely appreciate the honesty of this approach – no-one is ‘free-loading’ and, because of that, we seem to be able to support more ebb and flow in effort, reflecting the different skills and availabilities of students on the team.
Long answer – hope that it’s helpful! Thank you for the question.