Manish Pansiniya’s Blog

This one has come up before, but with a near year dawning, I think it’s worth revisiting.  Suppose you were about to join a new medium-sized software development project — a couple of dozen people, split between two or three sites, with a couple of hundred thousand lines of moderately complex code already written.  What would you do to determine how healthy the project was? Obvious things include:

1. Ask the team how positive they feel about what they’re doing. (Happy teams aren’t always productive, but unhappy teams almost never are.)
2. Compare their actual development practices against some kind of checklist.  (Version control? Yup.  Test-driven development?  No, but most people still don’t actually do that.  Some testing, with continuous build on the back-end, is a more reasonable expectation…)
3. Read their code.  In my experience, this is a lot more work than the previous two options, primarily because most projects don’t have a useful architectural overview.

What else? What would you do, and why?

Now, for bonus marks, what would you do differently if you were faced with a dozen teams, each with four to six people, and each having only ten thousand lines of code?  The first case is the one I face when consulting, while the second is what I have to deal with in the classroom. I believe that our collective failure to handle the latter case well is the main reason so many junior developers have trouble coping with real-world applications, which is in turn why intermediate and senior developers’ skills are so uneven and unpredictable.

Thoughts?

taken from : http://pyre.third-bit.com/blog/archives/1858.html