Those familiar with military aviation training methods and simulators will be aware of a fact which came to my attention just last week. During a meeting with a major UK supplier of military and civilian hardware and software, their representative reminded me that military pilots, once qualified, are most regularly trained in the tasks which they least regularly carry out.

While a pilot will be operating the undercarriage and trimming elevators or the rudder in every flight, he will hopefully never need to eject from the cockpit. However, should he ever need to, he absolutely must know how to go about it, the procedures that need to be carried out and the controls used to ensure his safe ejection from the cockpit and deployment of his parachute. To ensure that this is the case, he will regularly undergo cockpit ejection training in a simulator environment, but will rarely use a simulator to practise trimming procedures.

Whatever role we find ourselves in, most of us quickly internalize those activities which we regularly carry out. How does this relate to training software engineers?

During the last few years I’ve been disappointed to learn of the number of educational establishments which will teach many of the topics we’ve discussed only through a lecture format. Whilst I appreciate that projects are time-consuming to plan and run, my experience tells me that a student who is encouraged to use the techniques they learn in the context of a team project, will not only gain a better understanding of how a project is run and the project management techniques they’ve learned, but also will be more likely remember the likes of UML and SSADM.

Application of taught skills is, in my view, essential to the full learning and further development of those skills, and also gives the opportunity for students to experience them in something closer to a real world environment, rather than just in the sterility of the lecture hall.

The five key challenges I examined were:

• Keeping business processes and the solutions that support them closely aligned
• Maintaining investment in intellectual property within, or accessible to, the organization
• Understanding the hand-over points between client and supplier organizations
• Preserving interoperability of long-lived IT system assets
• Minimizing client risk through adherence to standards for development practices

Of course, these challenges are in addition to the risks that are associated with the management of outsourced activities themselves.

In times where standards-based process improvement is de rigueur, seen in the continued push towards CMMI levels 4 & 5, it seems strange to me that so often these activities don’t include the use of standards-based analysis & design methods. Even stranger is that the software assets which are being developed offshore are so rarely subject to formal asset management techniques which can help to not only control the assets, but also to widen their use within a component- or service-based approach.