Title: From the Academic Coalface

I read the Academic Coalface in the July C Vu with interest. The story is too familiar. During my second year at university we had a group exercise in compiler writing. The groups where determined by the lecturer at random. The marking scheme was explain as such (roughly from memory):

It took me three weeks to find out who the other two in my group where, as they very rarely attended any lectures, and apparently did not read their email either. By fluke (after bringing this to the lecturer's attention) I ran into one of them during week four, and managed to arrange for us to meet on the Wednesday afternoon in the student union bar for a drink to get to know each other and determine who did what. Fine we manage a meeting, we agree on a work package breakdown, and a further meeting in a week to discuss progress, I'm responsible for integration given I'm the strongest C programmer, one is doing the lex and the other the yacc.

Next week we have the meeting, unsurprisingly perhaps, little has been done by either of them, and I'm dependent on them to provide the base for me to integrate. We agree to delay to next week. Next week, only one of them shows up, He's "done" the yacc, being a pessimist I've done the lex by now and started on the yacc (but am careful not to mention this and offend him). We agree to chase the third person and meet in a week to discuss the documentation (requirements and design where provided by lecture notes, earlier exercises and the coursework description) which they will produce while I pull the code together.

We are now into week six, I am the only one to attend the meeting, having discovered that the yacc work that was done produced hundreds of errors, and was not for the correct grammar. Week seven I'm pestering friends for some help as I'm doing all of a group exercise myself. I draw the lecture's further attention to the matter, and am told that I'll have to sort myself out and accept that in industry I wont get to choose my team and this exercise reflects that. I'll just have to get my team organised.

Mid-week ten the third member re-appears, and has apparently had a guilt trip, he rushes out some documentation and we just about meet the deadline. Final marks for team work, I get 0% which significantly drops my overall mark for the work. The lecturer was certainly correct, in that in our professional lives we won't always get to choose the teams we would wish for, however I have not yet found an employer that would put up with someone never turning up for work.

While I'm on the subject it amazed me to have a lecturer that taught less than 30% of his lectures, instead he sent along a PhD student to fill in, who, incidentally, could barely speak English. Another lecturer clearly never bothered to run his example code through a compiler, it was so full of spelling mistakes and language errors, never mind the logical errors.

Fortunately I graduated in '98 and am now happily working for a company that I've been involved with since I did my work experience in the sixth form.

One of the jobs of management is to handle problems arising from dysfunctional teams. In the academic context your lecturer was 'management'. Yet another way in which this tale relates to real life is that junior employees are often reluctant to whistle blow to senior management.

Teams need leaders and they need mechanisms to deal with non-functioning members of the team. One thing that Universities should consider is arranging that teams are composed of students from different years. The marking criteria should be different. Last year students should be in leadership roles and marked for this. First year students should be largely in the coding area and marked for the quality of their code.

Of course the problem is that such schemes actually require work from the academic staff. Students must learn to complain. If example code does not work, this is a provable failure, if lecturers (who are paid to do the work) leave it to their PhD students this is clear failure to meet their employment requirements. What on Earth are the student unions doing?

Another group that could raise matters of concern are employers. These rely on the Universities and Colleges doing a proper job. If they are not doing so they should be taking issue with Department Heads, vice-chancellors etc.

Although the article was about a student project, the situation described is very much the essence of the situation that all too often occurs in the commercial IT world. I have recently been employed on a project where precisely this situation occurred, and my advice on corrective action was ignored. The result was a cost overrun of tens of millions of pounds, so I thought it might be useful to look at what went wrong and why, and what in my opinion a 'professional' response to the situation should have been.

The first activity: 'First two weeks meant to be formalising the spec...'. The Author does not tell us what initial documentation existed, although there is a comment later mentioning '..fulfilling mini-mum requirements..', so, was there a Requirements document? If so, was it formally reviewed by the team, and were test cases designed from it? If there was no Requirements document or if the Requirements were incomplete, ambiguous, untestable etc. the originator should have been immediately challenged to correct the deficiencies.

Now we come to a fundamental major mistake made by the Author, which helped speed the project on to disaster. A Capability Maturity Model level 1 operation is sometimes described as 'heroic', as the environment relies on the heroism of individuals to make anything work. Such an environment is typified by late and weekend working, daily crisis meetings, project schedules being continually changed, hack-and-try design, coding and release, ad hoc testing, poor configuration management, etc. etc. Still nothing works either as needed or reliably. Delivery of anything useful relies almost entirely on the conspicuous heroism of one or more individuals. The Author became Hero when he/she took it upon him/herself to write the spec. just before the deadline, and the Author continued as hero throughout the duration of the project.

This response is applauded in CMM level 1 operations, most vociferously by The Management.

A hero gets made 'employee of the month' or some such other divisive bullshit, as The Management feel relieved that here is the only person who just might get their nuts out of the fire. The truth is that whenever a hero appears, then the project will continue on its disastrous course rather than the deficiencies being properly addressed. This is the time to get out. My response is: Never make yourself a hero; it may seem the right thing to do at the time, but if the ship sinks, the hero goes down with it.

Another question is: was the Author really qualified to write a spec. in the first place? The writing of specifications is a technical skill in its own right, requiring a high level of knowledge and training. It is the domain of Analysts. It is clear from other comments in the article that the spec. had not been verified and fell far short of the mark, as it did not meet the needs of its audience.

The Author was to do testing and code walkthroughs. Specialist test analysis and QA knowledge and skills are needed to perform this activity properly, even on a small development. Did the team have those skills, or was this another facet of heroism? Were tests designed using structured methods? I particularly liked the comment that one of the Author's original assigned tasks was '...generally making sure it's all right.'

Even though there was no Manager (a positive feature...?!), management activities should have been carried out. Was there an identified project lifecycle and an accompanying schedule, with the schedule written directly in terms of tasks carried out against configuration items? It doesn't take long to produce a Gannt Chart ; it would have clarified the task durations, critical path and roles to be played by the participants to carry out various activities in the project, i.e. Systems Analyst, Test Analyst, Use-Case Engineer, or whatever.

The rest of the tasks seemed to focus on programming, with OOP mentioned. There is no mention however of any models of the system, which brings me to another fundamental point: Any analysis or design of a system can only be as good as the models of that system. This is true for any branch of engineering.

Although it may seem that I am flaming the Author, he/she acted from the best of intentions and is definitely to be applauded for writing the article and drawing our attention to a major problem in Academia. Overall, I think that the student exercise has caused the students to become accustomed to extremely bad habits right from the start. One of the worst hackers I've ever come across had a PhD in computer science.

The evidence from the article suggests that the Doctor or whoever it was put this exercise together knows little or nothing about software engineering management, and if the Doctor thinks that '..students' projects have improved tremendously..' then what the hell were the other projects like? My advice to the Author of the original article is that if he wants to become a good IT professional, find a better course - Fast!!!

Unfortunately the original author's academic institution is considered to have one of the better Computer Science Departments in the UK. It would have been interesting had the author provided a complete set of Gannt charts, etc demonstrating correct preparation followed by regular (lack of) progress reports to management as represented by the lecturer. Personally I would always keep copies of such and forward them to senior management if the early warnings did not prompt management action. It is time that our academic institutions recognised that learning is supposed to be an exercise in partnership.

You might be interested to know that I am currently in the midst of an email dialogue with a course leader for a multimedia course. The leader has come up with the idea that it would help students to learn about programming in something other than Visual Basic. Unfortunately she has no skills in C++. She has the sense to look for a guest lecturer to cover the subject. Unfortunately the time allocation is two 3-hour sessions each being 50% practical. The students are classified as largely ignorant of programming and generally extremely nervous about it. The course is due to start at the end of September and the proposed C++ element is provisionally scheduled for mid-October.

Almost at the same time an appeal for advice on a suitable C++ textbook appeared on comp.lang.C++.moderated. This for a course to in the first semester of the coming academic year in the USA. The level of experience of the questioner is exhibited by their mention of 'Teach Yourself C++' by Herbert Schildt. Too many courses are being designed and presented by the totally ignorant. I think we need some form of certification of academic courses. Perhaps institutions such as BCS, IEEE, ACM etc. could attack the root of the problem by at least investigating courses and publishing a classification of them. If I was still a schoolteacher and did such a poor job I would be (rightly) castigated by our (the UK's) schools' inspectorate. Well, I would almost certainly still get away with it in IT, but I wouldn't in more traditional subjects.

If we want a better-educated work force we must make the effort to provide better educated educators.