Small Packages

Several of the chaps on my course are in a similar situation to myself - they are competent IT professionals with a number of years of commercial experience who have decided, for various reasons, to go back to university. This creates interesting problems in a lot of the classes. With few exceptions, the lecturers have no professional experience and come at problems from a purely academic viewpoint, which can cause them to commit terrible blunders.

A good example of this was an astonishing “WTF?” moment when a database lecturer asked some students with commercial experience if they created views as an abstraction layer over a database before they started developing new functionality. He suggested that this could avoid disrupting a live application’s service, which would naturally occur if developers are slowly altering a database’s structure. Good idea if you are in the insane habit of developing on production databases. Bad idea unless you want to get fired on the spot.

These blunders do not sit well with the sensibilities of the experienced students, and some of the more vocal members of the class are not afraid to make their feelings known. Anyhoo, one student regularly pulled up one of the programming lecturers on problems with his code or methodologies. After a particularly fraught debate about XML, DTDs and the Java XML APIs, we got onto the topic of team names for the final group project.

“What’s your team name?” asked the lecturer.
“Big Things Come In Small Packages,” replied the student.
“Oh,” said the lecturer, with a glint in his eye. “Small packages.”