“安德的游戏”和软件开发

Ender's Game and Software Development		22 Jul 03
	[print link all]
I recently read the novel Ender's Game by Orson Scott Card. It's a science-fiction piece about a young child who is training to be the next military genius that can save Earth from devastating attack by an alien species. As I read the novel, four main themes jumped out at me as being very relevant to software development. The hero of the story, Ender, had many gifts and attributes, but I think these were the ones that made him a success: <!----> Harness Emergence <!----> Ender knew that the elaborate battle formations his peers were practicing were too rigid, rehearsed, and thus could be broken. In accordance with agile and emergent principles, he broke his battle team up into smaller, autonomous units. Each unit was given a strategic goal that he coordinated, but the tactical details of how to accomplish that goal were left to the individuals at the lowest levels. This defied the standard "command and control" logic that permeated the school, but quickly became a huge success as Ender's team won every simulated battle against larger and more experienced forces. We can harness emergent behavior in teams the same way, by pushing control down to the lowest levels and allowing team members the flexibility to adapt to changing situations on the ground. That's the whole point of agility, in business or in software development. But we can also harness emergence in our code the same way. Don't create an architecture with a single "command and control" entity that makes all the decisions in the system. That's bad OO design, right? Instead, you defer and push decisions down as far as you can, ultimately to the lowest-level object that has to act on it. <!----> Overwhelming Force <!----> Ender played for keeps; he wasn't a killer and yet he was able to kill readily when the situation warranted it. His opponents didn't necessarily know that, and attacked initially with less-than-overwhelming force. They never got a second chance. One might argue that Ender was overly violent and overreacted; killing without justifiable cause. But to Ender it was justifiable; he was simply playing to win. Playing with overwhelming force, leaving little to chance and leaving little risk of future conflict. The emerging military doctrine of "overwhelming force" has parallels in business and development as well. Overwhelming force is simply one way to address risk management. If you are SO well prepared and have SUCH greater strength than the opposition, then the risk of failure is minimized. The greater the dichotomy, the lesser the risk. Unfortunately, economic conditions in most companies take us into battle on a software project with "barely adequate" force. Instead, it's the project team that gets overwhelmed. But overwhelming force doesn't have to be overwhelmingly expensive. It just has to be sufficiently strong to win. Always play to win. <!----> Practice <!----> Remember the old joke where the tourist on the streets of New York asks the man "How do you get to Carnegie Hall?" To which the hip dude replies "practice, baby, practice." Ender and his battle teams practiced more than anyone else in the school. Outside of regular school-sponsored activities, Ender organized his own training regimen. They practiced constantly, and in the end, he and his disciples were so adept at the practice sessions that the real battle felt just like another practice. As Dave is fond of pointing out, practice is what makes you technically adept. The code katas that he posts on his blog are a first step in practicing the mental discipline and skills you need to become -- or continue to be -- an excellent programmer. Without practice, many individuals and teams resemble rookie football players that are dropped straight into the Superbowl, under the cameras and everything. The results are not pretty. <!----> Continual Learning <!----> One of Ender's most fascinating traits to me was his style of continual learning. That's a trait of Pragmatic Programmers that Dave and I have often suggested is the most important -- continually learning the technology, the people, the dynamics of the team, the problem domain, and even learning about yourself. Ender really specialized in this area, under the most remarkably poor conditions. Even when attacked by bullies, or unfairly treated by the authorities or peers, Ender's first reaction was neither anger nor fear. He simply "made a note of it." Enemies attacking in furor reveal useful information about themselves, information that can be used in a counter-attack. So Ender learned all the time: from his peers, his enemies, the authoritarian system, and from himself. And no matter what pain or humiliation was brought to bear on him, he decided to learn from it. We all make mistakes. But the biggest mistake is not to learn from them. Not a bad lesson from a work of fiction written about 20 years ago. -- /\ndy <!---->