Books or Articles On Splitting Up A Project Effectively

Question

I've been doing software development for a number of years but have always worked alone. Now I'm at a point where I need to hire other developers to help out. What recommendations would you have for books or articles on effectively splitting up a project and the best practices for checking the work of the developers as well as putting the pieces together?

Answer 1

It's old, and possibly not 100% relevant to your question, but if you've not read it, it sounds to me like you might find the Mythical Man Month useful.

Answer 2

You might find the Software Project Survival Guide handy.

Answer 3

This is going to sound funny given the connection between stackoverflow and the author, but I highly recommend "joel on software". the reason is that it was recommended to me by the owner of a company who is a software vendor of mine that I've worked with for years. That company has a great reputation for managing their team of people, preparing and delivering good scheduled, setting and meeting expectations and delivering good software. After I read "joel on software", I realized that they were mostly following similar principles to spec creation and schedule management that he lays out. In other words, for a small software company... it works.

I've been planning on starting up my own software company with the intent of developing specific products and I'll be adopting a similar model.

:)

-Adeena

PS - thanks joel!

Answer 4

"What recommendations would you have for books or articles on effectively splitting up a project"

Too many books are either managerial with a light touch on technology or too technical without much advice on getting things built.

McBreen's book on Software Craftsmanship might be helpful in thinking about what your staff's skills are and need to become.

Here are some lessons I've learned.

• Form follows function. So. First, define what it does. Then break it into intellectually manageable pieces. Conceptual integrity is key. You have to do all the decomposition so it reflects one point-of-view (good, bad or indifferent, unity of vision is very important for Those Who Come After.)

• Touch Everything. Do the initial development on each piece yourself. Then hand it off for completion. It saves a lot of discussion on how to get started. It saves a lot of pointless specification-writing. Rough it out. Provide skeleton unit tests. This is part of the conceptual integrity.

• Review Everything: the tests, the design, the documentation, the schedule. Converse heavily and deeply with the team. One-on-one is better than group meetings where most of the team is bored while you dig into a detail.

• Much time will be sucked into these conversations. Your personal "productivity" will appear to drop because you physically type less code. The more time you spend explaining and motivating, the more productive your team becomes.

"best practices for checking the work of the developers as well as putting the pieces together?"

• Review designs yourself and comment in detail.

• Review unit test code yourself and comment in detail.

• Review code yourself and comment in detail.

Consistency is critical here. Either have a great reason for everything, or -- if you don't have a great reason -- be consistent.

I'm 50/50 on group walkthroughs.

• Group is good for explaining things.

• Group may be good for spotting things you individually might miss.

• Group is a bad way to review a design where there are hidden architectural issues.

Example. We have three sets of mock data. And our tests happen to depend on one of the three. But we can't -- trivially -- assure that the right fixtures are in the right places for some of the tests. We have either a testability issue or a configurability issue.

It's my problem to solve. And the whole team doesn't need to be part of it. I've assigned the guy who was working on it to the next thing, and I'm working on the testability issue. I think I'll have something Monday or Tuesday.

Example. One of the developers has really poor writing skills. English is his first language, but you can't tell from his comments. I review all the check-ins by reading diff files. I make just a few English grammar corrections before each commit. Then fix the more subtle ones as I go.

Right now, our nightly build isn't automated. Or nightly. I have to run it manually after each check-in and each update that I do. The bugs go back into the backlog and get farmed out.

The hard part -- for me -- is keeping management status (simplistic) and a more useful backlog for myself and the developers. One tool with multiple reports is good. Since I don't have a nightly build, I don't have a complete inventory of tests. I can't report tests written vs. tests passing -- yet.

Answer 5

Just don't forget Conway's law, which has many variants, including the classic: "If you have four groups working on a compiler, you'll get a 4-pass compiler."

Answer 6

An oldie but goodie is Dave Parnas's article On the Criteria to be Used for Decomposing Systems Into Modules. Short version: encapsulate design decisions that are likely to change. Another one I like is also by Parnas On the Design and Development of Program Families.

On best practices, you'll want to be sure nothing gets checked in until it is seen by two pairs of eyes. You'll also want regular code reviews.

Finally, you've just become a manager. You'll need Peopleware by DeMarco and Lister. A lot of it is aimed at front-line managers in big companies but you'll learn enough to make it more than worth your time and money.

Answer 7

im with adeena RE joel on software (http://www.joelonsoftware.com/).

the reason being twofold: it doesnt require you to make a massive commitment to becoming an expert manager or software engineer - it gives you what you need now, so you can get on with your work and so you can pay your staff and bills.

if you want a begining point, i cant see anything better then joels 12 point test (http://www.joelonsoftware.com/articles/fog0000000043.html). pursuing this will lead to all the other necessary things.

when i started as a project manager 6 years ago in a small web development company, i had zero experience as a project manager. joel on software saved my ass, without a doubt.