One of my hobbies is historical conflict simulations, better known by their shorter moniker, wargames. Playing a boardgame that re-creates the Revolutionary War, the political collapse of the Roman Republic, or the battle of Gettysburg might not be your idea of a good time, but it's mine.
Wargames push my buttons as a history buff, and they often provide insights into historical events that other media cannot provide nearly as well. The challenges of wargame design echo the challenges people face designing other kinds of products. One of these lessons is the importance of having both designers and developers.
Developers make designers successful
It's tough to design a wargame. Anyone can throw together a game, using a board and a few bits, that might superficially resemble an historical event. Once you start playing, however, you'll immediately see that the game is about as realistic a depiction of history as Monopoly is a simulation of corporate management. On the other hand, to make the game more realistic, loading up the game with details to cover every facet of history will make a game that's superficially realistic, but unplayable.
Therefore, to simulate historical events through this medium, wargame designers must walk a fine line between credibility and simulation. Not surprisingly, they sometimes fail. A designer might devise a great new mechanism for simulating history, but draw a blank when it comes to making a playable, interesting game. Other designers might be very good at making playable games that, unfortunately, produce historically unrealistic results.
Enter the developer, the designer's partner in building a wargame. Where the designer might have a lot of good ideas, a developer knows how to make them work in practice. For example, a designer might have an interesting approach to depicting the importance of C3I (command, control, communications, and intelligence) in modern warfare. Unfortunately, the designer tried to simulate too much, creating an over-complicated set of game mechanics. At this point, the developer pares the C3I rules down to their essentials.
Development and design in the tech industry
The designer/developer partnership isn't limited to wargame design. In the technology industry, new ideas often have two inventors. Google has two founders, Sergey Brin and Larry Page, not one. Another duo, Evan Williams and Biz Stone, founded Twitter. In big companies, you'll also find a pair of "founders" behind new technologies.
Obviously, these creative combos work because the two people have complementary skills. One person might keep spitting out new ideas with machine gun rapidity. The other partner needs to be the person who identifies the ideas with the best potential, puts them to the test, and ensures that they move from concept to concrete reality.
Other aspects of the designer/developer partnership apply to the technology industry. In both wargames and software, the temptation towards complexity is always strong. Togo back to the C3I, the wargame designer might create one set of rules to handle how a general orders his troops, and another to depict how they respond to them. The developer steps in here and says, "All you're really trying to do is figure out whether this brigade moved, and if so, how far. So why not just have one mechanic to show the effect of C3I, rather than two to show the activities that produce these results?"
Similarly, partners in software development check each other's tendencies towards needless complexity. Elegant code is easier to build and maintain. Not surprisingly, there's almost a cottage industry unto itself of books about programming elegance.
The business partnership starts from Day One
There's more to this kind of partnership than good programming hygiene, however. Some of the most successful companies in Silicon Valley had, during key periods of growth, strong business leadership to complement technology acumen. Oracle may have a reputation for bare-knuckles sales techniques, but that's just another way of saying, from its inception, the Oracle management team had a clear idea of which markets to target, and how to convince people in these markets to buy Oracle's technology.
Corporate strategy and product strategy start from the first day of coding. The team may not yet include someone with these skills, but the need for these skills exist. If the initial architecture won't support massive scalability, or a multi-tenant deployment, then good luck moving someday from an on-premise to on-demand model. You may not need to worry about these concerns, if the best opportunities don't exist in a SaaS world. The team will make this type of design decision, with enormous business consequences, even if they make the decision unintentionally, by neglecting these questions.