Sample Case Study 2

Andrew McCarron — Wed, 08 Jul 2015 10:29:43 +0000

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam eu nibh porta diam sodales vestibulum. Nunc id leo hendrerit ex tempor ultricies. Sed tincidunt gravida diam. Duis bibendum lacus nec nibh tristique, ac euismod purus consectetur. Donec interdum vel eros malesuada semper. Donec vitae eleifend nunc, et congue enim. Morbi dapibus nisl lectus. Vivamus nec feugiat tellus. Integer eu tempus ex, sed tincidunt lorem. Pellentesque nec posuere justo. Sed aliquam eu nisl ut efficitur. In elementum massa sit amet elit venenatis maximus. Fusce vel elementum dolor, et ultrices libero. Suspendisse iaculis odio non felis lobortis, at vehicula ligula congue. Duis in elit aliquam, porttitor nunc non, ullamcorper risus. Phasellus congue magna vel orci congue, rutrum tristique libero tempus.

Sed semper purus vel sem molestie eleifend ac in metus. Suspendisse eget nulla felis. Nullam sagittis vitae turpis et laoreet. Aenean mattis interdum purus, sed lobortis ligula lacinia id. Aliquam rutrum faucibus tortor a egestas. Mauris vulputate metus erat, sit amet malesuada nibh bibendum a. In hac habitasse platea dictumst. Praesent euismod ex nunc, et sollicitudin sem dictum condimentum. Quisque quis volutpat ante, nec sodales odio.

Ut sit amet nisl vel nisi ultricies mattis. Aliquam vehicula id diam eget volutpat. Ut vel mollis massa, vitae condimentum metus. Integer vel porta dui. Donec vitae dui neque. Sed nisl orci, scelerisque sed augue non, luctus varius dolor. Integer fringilla est a est laoreet, a egestas dui convallis. Proin auctor velit arcu, quis posuere sem posuere et. Phasellus dui dui, rutrum in pulvinar sit amet, consectetur vel sem. Maecenas mauris dolor, tristique bibendum iaculis feugiat, lobortis a erat. Praesent eleifend sollicitudin libero, eget finibus sem consectetur ac. Integer malesuada molestie tellus, vitae laoreet ex semper et.

Vestibulum pretium varius nibh nec varius. Phasellus dolor libero, condimentum eget libero ac, congue commodo metus. Maecenas sit amet volutpat lorem, ac aliquam metus. Ut eu cursus risus, porta varius nunc. Mauris eleifend hendrerit tincidunt. Donec ut aliquet risus, at viverra libero. Sed a malesuada eros, quis luctus lacus. Sed vel turpis non massa dapibus facilisis. Praesent ut viverra elit. Vivamus pretium auctor est, eget aliquet leo ultricies non. Etiam nisi dui, imperdiet fringilla diam at, egestas convallis sapien. Pellentesque vel fringilla tortor. Maecenas nunc mauris, sollicitudin sed turpis sit amet, vestibulum lacinia justo. Fusce vestibulum nec nulla a dictum. Praesent dignissim commodo sapien, id eleifend ligula suscipit interdum.

Careers

Consultancy

You Cannot (Really) Teach Software Engineering

Mark Truran — Mon, 02 Mar 2015 16:00:25 +0000

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 north east 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 at Symbiosys Consulting. Dr.Truran's article originally appeared on LinkedIn at http://goo.gl/ydxWkS

Tags: