Re: [Sigia-l] Elements of Documentation
Listera <listera <at> rcn.com>
2002-07-01 08:03:03 GMT
> I personally think the idea of "make models and then push the button and
> have a website" will partially work: it will be good enough for
> prototyping, and small websites, the same way Visual Basic (a prototypig
> language really I believe, correct me if I'm wrong with this example) is
> good enough for small applications.
I'm not sure we agree or disagree on this but I'm against the strong
coupling of prototype to production code.
People who have no understanding of the intricacies of code writing should
not be in the business of showing/telling programmers what to do. The
prototype should show WHAT to do. The programmers should deconstruct it to
figure out HOW to do it in code. Mixing the two is asking for trouble.
That's why when I see UML charts done by IAs , business analysts, project
managers, GUI architects, etc., with method descriptions, classes, global
variables, etc., I want to reach for Prozac, AK47 or ice cream, depending on
the humidity outside.
My ideal is to give programmers a functional prototype (preferably done in a
language they don't know) and spend as many hours as they require to go over
every functionality. Step by step. Let them absorb it at their own pace. Ask
me all the questions and let them take their own notes, the way it makes
sense to them. My objective is to make sure that they understand each
functionality; not necessarily discuss how to implement it in code. That's
usually not what I get paid for (although, occasionally, I look at code to
optimize performance, workflow, etc).
I've seen ridiculously 'well-documented' apps, with specs amounting to a
medium-sized city phone book. You don't have to be a genius to figure out