“安德的遊戲”和軟體開發 (轉)
I recently read the novel Ender's Game by Orson tt 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 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 CarnegHall?" To which the hdude replies "practice, baby, practice."
Ender and his battle teams practiced more than anyone else in the school. Outs 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 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 lent programmer.
Without practice, many individuals and teams resemble rookie football s 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 ain, 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.
-- / dy words: katas blog Superbowl -->
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10748419/viewspace-963566/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 軟體開發的管理和控制 (轉)
- 自上而下的軟體開發和自下而上軟體開發
- 物件導向的軟體開發 (轉)物件
- 軟體開發的哲學思考 (轉)
- 論軟體的元件式開發 (轉)元件
- Linux下的軟體開發(轉)Linux
- 軟體開發的專案管理(轉)專案管理
- 日本軟體開發的度量取向(轉)
- 軟體開發隨想 (轉)
- 曦潮薦書┃安德的遊戲遊戲
- 小軟體專案開發的管理 (轉)
- 小軟體專案開發的管理(轉)
- 軟體開發中的專案管理(轉)專案管理
- 軟體開發專案的風險管理(轉)
- 對軟體開發的一點心得體會 (轉)
- vb開發通訊軟體 (轉)
- 馬克·安德森:軟體正在佔領全世界
- 精益思想和軟體開發
- 軟體開發:app軟體開發,pc端軟體開發,微商城/小程式開發APP
- 行軟體開發中的專案管理 (轉)專案管理
- 談軟體開發過程的改進 (轉)
- 【轉載】軟體開發模式簡介模式
- vb開發通訊軟體(cloud轉貼) (轉)Cloud
- 基於構件的軟體開發的發展方向 (轉)
- 軟體開發與軟體研發
- 淺談軟體開發模型之瀑布開發和敏捷開發模型敏捷
- 軟體開發的難
- 軟體開發人員的組織與分工(轉)
- 再談軟體需求分析和開發
- 【開源軟體】Ngrok——內網轉發神器內網
- 軟體開發之3S方法(轉)
- 軟體“吃”掉了軟體開發
- 軟體開發mac常用軟體Mac
- 軟體開發中的精益和敏捷 - Aram Koukia敏捷
- 基於Azure的軟體部署和開發系列沙龍
- 工具和敏捷軟體開發之間的關係敏捷
- 國內應用軟體開發管理的探討 (轉)
- 軟體開發:需求分析的20條法則(收藏) (轉)