I've read a lot on FDD but haven't had the chance to put it into practice properly as yet and I really won't be able to for some time as I'm starting a solo venture.
If all goes well I'd conceivably have others working on the project with me at some point in the future. I'd like to start the project using best practices and a methodology that I could continue as I moved from being a one man show to a two, three, four person outfit.
Does anyone have any tips on how to best use the practices from FDD that are compatible with a single developer and what to do in lieu of those that aren't?
I like the visibility that FDD provides and as a single developer I think you need something that gives you an honest view of the progress of the project rather than your own biased gut feeling. With Reece's new FDD Manager it looks as though the overhead in producing the reports would be negligible, even if nobody else was going to see them.
One area where FDD doesn't seem be so appropriate for a single developer is the emphasis placed on code inspections. Does anyone have any suggestions on how to overcome this issue?
Perhaps I could convince a friend to devote a night a week to coming and doing an inspection with me. Maybe there are other single developers who would trade inspections, "I'll inspect yours if you'll inspect mine". Maybe I leave a few weeks inbetween writing the code and inspecting it myself so that I'm not quite so close to it.
I don't really like any of these much, has anyone else got any better suggestions?
Regards,
Lachlan
FDD for one
Lachlan,
Have a look back at a previous thread on this subject: FDD in the small.
From my point of view the five steps and the artefacts mentioned in FDD apply basically without change in very small teams. You still work on an overall design based on the domain walkthrough, build feature lists & feature sets, and so on.
The processes on the small scale change, mostly by removing 'team' activities.
As you rightly point out, inspections are a big casuality on teams of one. If you don't have another pair of eyes available then you just can't do proper inspections.
I'll review my own code once in a while (usually picking bits that I think are complex or troublesome). Whenever another pair of eyes is available I will ask that old code is reviewed.
As Paul sugested in the earlier thread reviewing code from a page rather than the screen can help you see it in a different light, so helping you pick up different problems.
Brian.
Well Said
Very well said Brian.
Paul and I essentially operate this way a lot on internal projects. What I think is worth noting is the importance of the features list (FBS) to meaningful progress and tangible outcomes. Even if extensive modeling is done, without the FBS, you have no visibility into the construction phase and all the usual progress and outcome problems emerge. i.e. you are busy all the time because you really are busy- you are coding (or whatever) but without the focus of the FBS and the focus on achieveing (completing) small results that add up to bigger ones, you just don't make the same kind of progress or create the same kinds of deliverables along the way.
I know this sounds a bit like motherhood, but I really can't stress it enough (from experience).
Jeff