We discussed how it often seems that it's easier to introduce the management practices of Scrum than the engineering practices of XP. Esther asked me why I thought this was the case, and a thought struck me - it's how the developers were trained.

(Warning - here comes yet another aviation analogy!)

During my flight training, my first instructor made a point of saying early and often that it was very important to listen closely, do what she said the way she said to do it, and to practice that way afterwards. She emphasized the importance of this, saying that "when faced with an emergency, you'll revert to your original training". That was in 2005, and even now I hear her voice in my head when I'm flying and practicing things such as forced landings.

How does this apply to software development? Well, consider the poor overworked software developer. They've had this bloody Scrum process thrust upon them meaning they have to deliver more, deliver it faster and have those annoying business people around all the time to pester them. On top of it, the damned "Agile Coach" is harassing all the developers to write more code that tests the code they've already written. Near the end of the sprint, this poor developer is running out of time and still has work to complete - they are facing an emergency! So what do they do? They revert to their original training.

What was that training? If they went to university or college, likely long hours working alone or in very small groups trying to get assignments done. They hacked something together that met the requirements for the assignment, and could afford to make it throwaway. Automated tests? BAH!! Simplest thing that could possibly work? How's that going to impress the prof? In the end, the attitude is to get something - anything - done in order to get the marks.

It's this training environment that leads to the problems when the developers are "faced with an emergency" later in their careers.

I suspect there's another hold over from early training that influences they dynamic. The system in most schools inculcates the idea that whatever we turn in is the final product; there's no improvement cycle.

I think there's another hold over from early training that influences the dynamic. Most school systems inculcate the idea that once you turn something in, it's done. Whether it's D work or A work, there's no improvement cycle.

I like the story, but I'm not sure there's an equivalent "Original Training" when talking about software development.

To fly a plane you need to know a rather large body of knowledge cold before you can take off, and the initial training is probably the most intense learning the pilot will undertake.

In software development, your knowledge grows incrementally from the outset and at each point of the way you become more proficient. So, if developers are reverting to their Original Training, it's probably not their development skills they're reverting to, but is more likely just their general common sense approach to solving problems.

If you follow my train of thought (and you're free to throw it out), it lends itself to saying that developers push back against the practices not because of their initial software development training, but because they don't seem intuitively correct.

To fly a plane you need to know a rather large body of knowledge cold before you can take off, and the initial training is probably the most intense learning the pilot will undertake.

Actually, Allain, you don't! Instructors will have you flying the aircraft within an hour or so after a briefing & walkaround. They handle takeoff and landing, but you get to fly a portion of the first flight. It's actually a very incremental learning process, gradually introducing newer and more complex concepts as you learn. As you progress, the mental workload decreases as tasks become memorized.