Brennan’s Blog

In college nearly every lab project was a started from scratch. Either I was given a task to complete on my own or I would work with a team. That was a great experience but after years of working in the real world I am finding that it would have also been helpful to be put in the position to support a legacy system over the course of a few semesters. I have read numbers which show 80% of time (or budget) is spent on maintenance. It seems my education focused only on 20% of the work I would be doing in my career. But perhaps this is not true for all schools.

What is important to teach about maintaining software is that often you will be tossed into a legacy system which was designed and built using older tools and older ideas. The current status quo or what you may have been taught was the "right way" is not how the software was created. So you have to cope with that fact. You must learn to adapt to that systems way of doing things and perhaps develop a migration strategy to move it forward to use new techniques, languages and tools to reap the benefits of modern improvements.

While I was in school a good portion of the classes touched on COBOL which was once the golden hammer of business applications. It ran the workflows of major businesses near my college and it would not be replaced anytime soon. So it remained on the curriculum. At the time Java was really starting to take off and was seen as the new golden hammer, but you had to still keep a foot in both worlds.

I have never had to touch COBOL since I left college, but I did work with Perl which was quietly being used at a large company to manage their financial data but the plan was to migrate to Java. It was interesting to develop the migration strategy to Java. The project managers and developer had discussions on the various choices for months before we got started. We focused largely on updating the software, but did not really consider the experience and aptitude of the staff. We all independently had to rework our skillsets to meet the plan. Some were eager to move to the new technology while others were content with the existing environment so there was a mix of sprinting and feet dragging. The mixture caused some undo pains as we all proceeded along the learning curve. And during this critical migration we were given a new project manger who replaced our previous manager who offered a deep understanding of the legacy system and the new Java technologies. That presented another complication for the project.

Often we would have to interpret what the legacy system was doing and try to remake it in Java. And the business logic and requirements had to be tested with the stakeholders. That whole process had to be learned on the job.

What I would suggest to a college professor would be to have the students create a new application in their first couple of semesters and then have to maintain each others applications in later semesters. I would have them grouped as teams, and with each semester the teams would change while Teachers Assistants may take on the role as Project Manager or Architect to simulate how things work in the real world. Teams are always changing at a real company so it is best to have the students experience that. I believe this would give new graduates a much more realistic view of software development for their first job after school.