Last year I consulted part-time in a R&D telecommunications firm.

 I worked in a cubicle 2-3 hours each afternoon and full-time on breaks and during the summer.

 I billed over 800 hours from January through November.

 I was the Server Engineer on a project to install a prototype ATM network linking five manufacturing and engineering sites in the eastern US.

 The project involved 30 employees in a company of 45, plus several external consultants.

 I was able to observe from day to day

 I have taught the software engineering project course for nearly 20 years with only tangential exposure to industrial practice.

 I have observed a variety of approaches to this course in text books and watched the growth of an undergraduate discipline of software engineering.

 I have seen in the literature and at conferences a very clear difference in perspective between practitioners and theoreticians.

 I have heard myself say repeatedly "you will need to understand this to be successful on the job" simply because it said that in the text.

 There was too much in the text to emphasize it all, and I had doubts that I was sufficiently informed to validly pick and choose.

 The computing environment and paradigms within academic computer science had changed dramatically in the past twenty years, yet there was scarce indications in the text book that similar changes were affecting industrial practice [for example, CASE has come and gone (been absorbed into other products) in industry, but continues to have the same exposure in text books (a good idea refuses to die in academia)].

 I felt uncomfortable pontificating to students about their future environment and its essential skills when I had only second hand glimpses of what it would be.

 It was not very difficult to arrange the "internship" and the company was willing to adapt to my limited availability.

 I witnessed the impact of organization politics, management styles, and technical decision making procedures.

 From my association with external consultants I had a basis for extrapolating what I experienced to the broader industry R&D sector.

 I acquired a great deal of technical information about networking and servers.

 I worked as part of a team [an experience non-research faculty have rarely].

 I obtained a better perspective on my software engineering text book and a clearer sense of priorities for the project course.

 I gained considerable credibility among my students.

 I made some very useful contacts within the technical community of Shreveport.

 It has strengthened my emphasis on documents [documentation drove the telecommunications project].

 It has shifted my emphasis towards requirements specification.

 It has increased my appreciation of scheduling milestones [project status was a constant concern of management].

 It has increased my emphasis on team organization and mutual responsibility.

 It has made me more aware of the reliance placed upon the judgment of professionals [this may be restricted to engineering environments, but it lends new meaning to the term software engineer].

 It has dissuaded me from the perception that good projects are those that are cut and dried, done by the book, on schedule and under budget.

 The company was forced into bankruptcy after being shut down by the FBI as part of a grand jury investigation of misuse of federal funds.

 A new company has been created in Shreveport to exploit some of the application concepts pursued by the old company, and many of the same employees are involved. A broader public/private partnership is evolving in which the University and the author (will) may play a prominent part.

 The software projects course this year gave greater thought to project selection and application requirements. More emphasis was also placed on scheduling and on quality assurance than had ever been attempted before, but with limited success.

 My two software project teams were uncharacteristically homogenous and worked fairly efficiently to implement their projects. (Steps which I had taken to facilitate communication were not utilized or appreciated.)