[Namaste-dev] Re: Weekly Plan June 2 - June 6
kb5mu at amsat.org
Tue Jun 3 10:25:49 PDT 2008
At 11:05 AM -0400 6/3/08, Frank Brickle wrote:
>Just to be clear, I don't think you're advocating the such an idea at all, but it's possible to interpret the intention stated here as mandating one particular design and development process.
Well ... maybe we don't agree so completely as all that. I AM sorely tempted to say that I do advocate mandating some aspects of the development process. If I were in a rabble-rousing mood, I would say that I want to mandate "engineering" and prohibit "hacking". This is a production development project we have here, or so we hope, not an experimental R&D project, to whatever extent it's meaningful to say that about an amateur radio project.
Now we're into the meat of some of the questions I hoped would be addressed by a project statement about openness. Excellent! I hope some more team members (especially the non-zealots) will chime in.
> For some of us, progressive sketches of program code effectively *are* the design documents.
That kind of design often works well for *implementation*, especially of a fairly localized item like a computer program. But before you start that procedure, you'd better have a clear idea in mind about what the requirements are. Often on a pure software project, the requirements can't usefully be set out in advance. This is because the basic requirements are too obvious to bother with, and the detailed requirements are too fluid to be specified in detail in advance. However, it's a mistake to assume that's going to be true in all cases. In a project with specified goals, you'd better spend some time trying to identify the requirements up front.
I'm not a big fan of documents that try to specify the detailed implementation in advance. Those are the kind of documents that can usefully be replaced by the progressive-sketches approach, and that's great. It's the *other* kinds of design documents which I believe are especially useful in an engineering project. These include requirements documents and high-level architecture documents. These set a framework for the implementation and make it possible to talk concretely about whether we are all building the same thing, and whether it's the right thing to be building.
Interface documents lie in the gray zone. It's important to finalize them early, but they are often dependent on implementation details that can't be optimized in advance. I'd like to see interface documents treated like requirements documents, but with a greater freedom to make changes late in the development.
I realize that asking for documents may seem bureaucratic to some people. I hope we can agree that it's a necessary part of the process of collaborative development.
kb5mu at amsat.org
More information about the Namaste-dev