This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: A good Rails team?
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
A good Rails team will consist of programmers who know what they should be doing, and usually have the discipline to do it. They have a good, solid grounding in software design principles and development practices, and a good track record of sticking to them on real projects. Such a team will fall right into the Rails way of doing things, seeing an environment where many of the barriers and obstacles fall away and they can do good work with less effort. This kind of team will see big productivity increases once they get the hang of Rails.
Now, substitute "Rails" with "My Framework" and realize what a generic statement this really is. Glenn is describing a good programming team (which he confesses later). There's nothing that speaks specifically to Rails here. So, let's cut the bullshit. The ideal Rails team consists of the following:
* Web designer, who also knows (some or more) Ruby, and a little (or more) about databases * Database specialist, who also knows (some or more) Ruby, and a little (or more) about web design * Ruby expert, who knows some (or more) about database and/or web design.
For dynamic languages, substitute "Rails" in my list with "MVC".
Actually, you can get away with just two people, depending on how much domain overlap there is, though the third person is also good for the dreaded "hit by the bus" scenario (and vacations). Three is also a lucky number in general - number of licks to the center of a tootsie roll tootsie-pop, number I have my vi tabstop set to, number of limbs Martians have - you get the picture.
And before anyone gets on my case about the fact that a single person may very well be able to "do it all", remember boys in girls, in a real production environment, you never want a single point of failure.
Previous Topic
