Contribution 61

From WikiContent

Revision as of 22:06, 2 July 2008 by Rmonson (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Dwarves, Elves, Wizards, and Kings

In Cryptonomicon, Randy Waterhouse explains his classification system for the different types of people he meets. Dwarves are hard workers, steadily producing beautiful artifacts in the dark loneliness of their caves. They exert tremendous forces moving mountains and shaping earth, and are renowned for their craftsmanship. Elves are elegant, cultured, and spend their days creating new and beautiful magical things. They are so gifted they don't even realize that other races view these things as otherworldly almost. The wizards are immensely powerful beings almost completely unlike all others, but unlike the Elves, they do know about magic, and its power and nature, and wield it with supreme effect. But there is a fourth type of character that Waterhouse alludes to but does not mention specifically. The Kings are the visionaries who know what must be done with all of these different characters.

An Architect is a King of sorts. The Architect must be familiar with all of these characters, and ensure that the architecture has roles for all of these characters. An architecture designed only for one will only attract that one character to the project, and even with the best dwarves, or elves, or wizards, the team will be severely limited in its reach if it can only approach problems in one way.

A good king will lead all types through a quest, and help them work together to complete it. Without the quest, there is no vision for the team, and it ultimately becomes a partisan mess. Without all characters, the team can only solve one class of problem, and is stopped at the first barrier impassable to that solution.

The architect creates the quest with all the characters in mind. The architecture then becomes a guide for finding tasks for the different characters to perform while learning about each other. When a project encounters difficulty, the team will already know how to approach solving it because the architecture gave them the opportunities to grow into a team.

By Evan Cofsky

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools