How Do You Determine the Health of a Software Development Project?
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:
- Ask the team how positive they feel about what they’re doing. (Happy teams aren’t always productive, but unhappy teams almost never are.)
- 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…)
- 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.
taken from : http://pyre.third-bit.com/blog/archives/1858.html