Zane has been starting a company called Liquid Labs. The concept is fairly similar to what Chuck, Arley and I are trying to do with Netzah. He wants to build up a library of software and software frameworks and to use them to develop products. I had believed there was a significant management style difference that might make it hard for us to work together should our paths cross.
There is somewhat of a difference. However are approaches to the problem are very similar. Both of us view software as an artistic process with engineering components. We both seem drawn to the artistic aspects of the problem and enjoy framework architecture.
The difference is that Zane believes you need a single individual guiding the artistic integrity of the project while I want a team to balance out the bad decisions an individual will make from time to time. Zane and I spent much of the discussion using metaphors from building architecture. The basic argument is that the really great architectural wonders are the brainchild of one person. I agree. I also think that even really great minds have a lot of bad ideas. I cringe when I think of all the writers who achieved significant market success and no longer felt constrained to listen to their editors. I believe the benefits of a strong team outweigh potential losses in technical unity.
Of course it is also not completely clear exactly what the difference in methodology is between Zane and my approach. Neither of us believe we can get the jobs we want to do long-term done without a team of people. We both realize it is important to listen to the team and that everyone has bad ideas. The difference seems to lie in whether there is a single person responsible for artistic direction. Or perhaps put another way, is there a category of decision that should all be made by one person in order to achieve some unity of concept; for these decisions, the justification that the artist wanted it done that way would presumably hold significant weight even absent a compelling technical justification.
Zane may be right; you may get better architectural unity that way. I know I experimented with similar claims at various points at fundsXpress. However I do know that I seem to be able to produce a better final product in a team that is fairly close to a pure consensus model. I end up spending a lot of time picking the members of the team. But everyone seems to make enough mistakes that you end up getting a better technical product if you can come to consensus on raised objections rather than simply going with one person's decision. Even having that one person listen to the input of the team actually gets you surprisingly little of the improvements of a consensus process. It's very easy to listen to someone's objections, possibly even take the time to understand them, think about the situation and conclude that after considering their input you are still right. The consensus process forces you to focus your thought and to actually come up with a correct explanation of why you are right. At least for me, my thinking tends to be different after having gone through this additional effort enough of the time to make it worthwhile. Of course to make consensus based teams practical as a business tool you need to avoid wasting too much time on process; that is important but out of scope for this discussion.
So why not combine the approaches and have a consensus team with an artist, realizing that the justification for why decisions affecting the esthetics of the product are made will often be because the artist said so? In practice I've been on a lot of teams that worked that way and in several cases been the artist. However I think formalizing this would lose the second big advantage of consensus teams for me: you can have multiple first rate people on a team. My interest in consensus decision making actually stems from a need to have multiple artists at early FundsXpress. I was starting to fill that role and was enjoying doing so. But there were a lot of other strong designers around then and they didn't want to work on a team where someone else was the head designer. And I certainly didn't want to let one of them become head designer after I had started filling that role in practice. But the option of not working with so many other good designers was also unacceptable. So I ended up stumbling on consensus-based processes as a mechanism to keep people happy. And not surprisingly, our product improved.
Note all of this is my reason for preferring a different approach than Zane. I like what I like because it works better for me knowing what I now do. I have a lot to learn to decide whether I think any of this reasoning has global applicability. I also don't know how to handle the technical unity problems very well and that's one of the areas I'm still trying to learn about.
I look forward to seeing how my thoughts on these issues evolve. The goals are now clear. I want to create software engineering art with strong technical unity. I also want to find ways of involving many first-rate designers and programmers in the same project. It's frustrating how few of my friends manage to work on the same projects. Part of this is economic; as my friends become more skilled their price goes up and it is harder to afford a lot of them. But even if you could afford all the good software people I know, how many of them would actually work well together? Having a peer group of similarly skilled engineers working on the same project has been the best experience of my life. So it's not surprising that I'm looking for processes and methods that at least for similarly minded engineers can increase the likelihood that we could successfully work together.