I am very lucky. I have actually had two careers. In the first, I taught software engineering at various UK universities. In the second, I moved to the private sector, working as a software consultant in the northeast of England. In this short article, I explain why it is so difficult to prepare computer science students for employment.
Mind the gap!
If my experience is typical, the gap between writing code in the ‘real world’ and software engineering as taught by UK universities is wider than most employers realise. This is not a criticism of the places I have worked. They are both excellent. The problem seems to affect the higher education (HE) sector as a whole. It boils down to this. There are certain activities inherent in real world software construction which are difficult (or impossible) to simulate within academia. Students who never engage with these activities leave university poorly equipped for their chosen career. To elaborate this point, here is a list of some of the skills that HE cannot (really) teach.
Requirements analysis
A computer science assignment at undergraduate level is a clearly expressed programming task, accompanied by an exhaustive set of assessment criteria. Contrast this with a ‘real world’ project. Authentic projects typically begin with a somewhat hazy set of requirements, combined with imprecise success criteria. This information is iteratively refined as the software developer interacts with the client, teasing out (or eliciting) what he/she is supposed to be building.
Since undergraduates are usually given a complete blueprint of the thing they must construct, or told to develop their own blueprint, this valuable skill of requirements analysis is never practiced at university. There are a few exceptions to this rule (e.g. final year projects with external clients), but they are few and far between. The human aspect of software construction (i.e. working with clients to find out what they actually want) is generally neglected in HE. And this is a real shame for everyone concerned.
Managing change
The next major difference between commercial software development and software engineering in HE concerns change. Once an academic assignment has been released to students, it is hardly ever modified. The task, the expected outcome, and the scheme for assessing that outcome, are entirely static. Subsequent changes to the specification can, in fact, trigger student appeals.
Outside of the campus, things are completely different. Rapid changes in requirements are, in fact, the norm. I have listened to telephone conversations in which the fundamental nature of a commercial project has changed in seconds. The software life cycle is entirely capricious, which means that managing change is an important skill for all software engineers. However, it is very difficult to teach this skill as part of a university degree. Assessment regulations simply do not permit arbitrary changes in project scope or evaluative criteria mid-way through a module.
Dealing with legacy code
The next serious disconnect for the recent graduate is the problem of legacy code. In general, computer science assignments are isolated and ‘green field’ in nature (i.e. the student is writing code from scratch). When a graduate starts work, chances are they will inherit a badly maintained project full of undocumented hacks and exotic dependencies. They will be forced to use outdated libraries and deprecated tool sets. They will fight with hand me down projects that won’t stand up, and spend fraught hours attempting to decipher gnomic read me files. They will do all this because it is the nature of the job. Unfortunately, it is not a part of the degree that preceded it, which is a tamer beast altogether.
Scaling it up
Size is important. Don’t believe people who tell you otherwise. The average undergraduate project comes in well below 2000 lines of code (LoC). Real projects are usually larger by 1-2 orders of magnitude. This can create huge difficulties for recent graduates, who are overwhelmed by the scale and complexity of the projects they are assigned. Obviously, it would be a huge technical challenge to embed larger projects into the undergraduate curriculum, but it would definitely help graduates hit the ground running.
(Actually) working with others
Computer science degrees usually have group work modules, so it seems universities have this one covered. Well, they do and they don’t. When a team of 5 undergraduates get together, there is a fairly predictable pattern. 2-3 of the students take ownership of the work, doing the vast majority of the heavy lifting. 1 student will be effective enough to avoid notice, but no real help. The remaining student will miss all the weekly meetings, ignore team emails and contribute nothing to the deliverables.
The use of anonymous peer review schemes (in which the students score each other) does something to address this problem, but group work is still disliked by all concerned because it tends to be unfair. As an introduction to collaborative work, group assessed modules are extremely problematic. University is really about individual performance. It is very hard to graft collaborative work into this environment. A 4-month group assessed module simply cannot emulate conditions in the field, where professional respect and the threat of disciplinary action (usually) prevent uneven contributions to work.
Conclusion
The title of this article is, of course, deliberately inflammatory. You can teach software engineering. I did it myself, and enjoyed every moment of it. I hope that the students I taught got something out of it. However, on reflection, I think there was something missing in my modules. Some of the most valuable skills needed by a software engineer are experiential. And it is very hard, maybe even impossible, to create these experiences in the classroom.
This leads me to a number of suggestions. They are not particularly controversial:
- Students – Whilst at university, find an open source software project and become involved. Commit code. Ask team members to review your code. Build anything for anyone. Do a placement year. This means one more year at university, but you will be a much stronger graduate.
- Employers – Recruit graduates who did a placement year, or who can point to a live project they worked on. In the long run, this will save you time and money.
- Universities – Continue to promote placement years. Encourage students (via entrepreneurial clubs) to engage with local businesses and produce software for them. Adapt your assessment strategies to better reflect real world conditions.
Mark Truran is a software and application developer. Dr.Truran’s article originally appeared on LinkedIn at http://goo.gl/ydxWkS
Author
