Getting good architecture
In my last blog, we talked about how we, in the Project Darkstar core team, try to insure that the code that goes into the project is of high quality, even though we are a research project. We talked about code reviews, and writing lots of tests, and all of the other things that need to be done to produce code that you can count on.
But a commenter rightly pointed out that all of these sorts of safeguards only work if you have a reasonable system design or architecture to begin with. Without such an architecture, all the testing and reviewing in the world aren't going to give you a high quality system. Instead, you will be spending all of your time and effort trying to overcome the intrinsic shortcomings of the architecture, and probably failing in the long run.
I've written about what it takes to train people to produce good system designs, and there are others (such as Fred Brooks) who have studied the problem a lot more. It's a hard problem, and so far the solution that I've found to be the most convincing is the least helpful, at least to management. That solution, simply put, is that if you want to get a good system design, hire (or pick from your current hires) someone who has done a good system design in the past, and get out of his or her way.
My own experience has been that there isn't a single process that good designers use to produce a good design. What works for one person is different from what works for someone else, and you can take someone who is a good designer using one approach, force them into using a different approach, and end up with something that is not going to be a good design. And there are some people who are just incapable of good design-- this doesn't mean that they aren't good people, or even good engineers, but there is something lacking that keeps them from being able to distinguish between a good design and one that is not so good.
One of the great things about the Project Darkstar core engineering group is that we have a number of very good designers on the team. In fact, the whole team is made up of people who know what they are doing when they approach system design problems. There are different styles within the group. Some like to prototype, others (like me) tend to work in a top-down fashion where all of the interfaces get defined first, with specifications, and then the implementations follow. Others do some variation of the two. We don't insist that we all design in the same way. But we do insist that we all design.
We also talk a lot about the design. Some of the talk is on email (you can join in if you want, or just watch; the email list is dev@games-darkstar.dev.java.net, and you can sign up here). Some of the talk is in meetings. And a lot of the talk is in the hallways or in someone's office, when one member of the team drops into another member's office to talk through some design. There is nothing like explaining a design to someone else to help you find the flaws in the design, and there is nothing like someone else hearing the design to let you work out all of the details.
In fact, more and more I find that I consider architecture and design a team sport. The basic idea of an architecture may come from one person, but fleshing out that idea into a full design that makes sense and can be implemented is a lot easier (and maybe requires) others. Talking about it, writing about it, and thinking about it will make the design stronger. It requires a team that trusts and respects each other, and is willing to ask each other hard questions when needed and offer support when things look grim. But once you have such a team, the designs get better, and coming up with the designs is both great fun and very rewarding.
