Comments on: Top down vs. Bottom Up http://www.shanebrady.com/2006/07/30/top-down-vs-bottom-up/ Just another WordPress weblog Fri, 5 Dec 2008 12:05:04 +0000 http://wordpress.org/?v=2.6.2 By: Mike Rowehl http://www.shanebrady.com/2006/07/30/top-down-vs-bottom-up/#comment-209 Mike Rowehl Sun, 30 Jul 2006 21:10:58 +0000 http://www.shanebrady.com/2006/07/30/top-down-vs-bottom-up/#comment-209 Hey Shane, thanks for the comments and kind words. Interesting that you put down three senior developers. That's where I draw the sweet spot for that as well. One is too few, you need someone else with a deep understanding to throw ideas around with. With two however you run the risk of frequently deadlocking on issues if you hit a major idealogical rift with respect to what to work on and how to do it. With three however all issues tend to tip toward some kind of resolution, but the size is small enough that everyone can be directly involved. Another pattern that seems to emerge frequently around here (Silicon Valley) is the surgical team style group like that described in The Mythical Man-Month (http://www.dfpug.de/loseblattsammlung/online/workshop/design_patterns/sonstiges.htm) It doesn't follow the same exactly layout as described there, but tends to be a group of folks that move around as a group and tend to have relatively consistent roles. One person is the tools person that puts together the parts needed to build with, two will be builders concentrating on what the user facing parts look like, another will be the overall architect concentrating on scaling and performance issues. Don't forget a sales person in your mix however. Marketing is one thing, but having a closer who has a rolodex of people to call and the skills to negotiate deals with them is another thing entirely. I think 4 junior developers is a bit heavy at the early stages too. Junior developers need oversight and guidance normally, and that needs to come from the senior developers unless you want to put a dedicated manager in there. Maybe one or two particularly good junior developers who can pick stuff up around the edges on their own. Otherwise you're putting unnecessary load on the senior guys with minimal return. Hey Shane, thanks for the comments and kind words. Interesting that you put down three senior developers. That’s where I draw the sweet spot for that as well. One is too few, you need someone else with a deep understanding to throw ideas around with. With two however you run the risk of frequently deadlocking on issues if you hit a major idealogical rift with respect to what to work on and how to do it. With three however all issues tend to tip toward some kind of resolution, but the size is small enough that everyone can be directly involved.

Another pattern that seems to emerge frequently around here (Silicon Valley) is the surgical team style group like that described in The Mythical Man-Month (http://www.dfpug.de/loseblattsammlung/online/workshop/design_patterns/sonstiges.htm) It doesn’t follow the same exactly layout as described there, but tends to be a group of folks that move around as a group and tend to have relatively consistent roles. One person is the tools person that puts together the parts needed to build with, two will be builders concentrating on what the user facing parts look like, another will be the overall architect concentrating on scaling and performance issues.

Don’t forget a sales person in your mix however. Marketing is one thing, but having a closer who has a rolodex of people to call and the skills to negotiate deals with them is another thing entirely. I think 4 junior developers is a bit heavy at the early stages too. Junior developers need oversight and guidance normally, and that needs to come from the senior developers unless you want to put a dedicated manager in there. Maybe one or two particularly good junior developers who can pick stuff up around the edges on their own. Otherwise you’re putting unnecessary load on the senior guys with minimal return.

]]>