Slashdot Mirror


Documentation Strategies?

An anonymous reader asks: "I'm a developer and have been given a task of creating documentation, for fellow developers, on how the system (a CMS) I have implemented, and adapted, works and how to develop for it. On the surface it doesn't seem too complicated but the amount of information I need to get down on paper, and the level of detail needed on some parts, is great. What's the best way to approach this task when there's so much information bouncing about in your head you don't know where to start?"

4 of 55 comments (clear)

  1. Hello McFly! Anybody Home? by Anonymous Coward · · Score: -1, Flamebait
    What's the best way to approach this task when there's so much information bouncing about in your head you don't know where to start?

    Ummm... Getting busy instead of posting dumb questions to Ask Slashdot?

    1. Re:Hello McFly! Anybody Home? by Anonymous Coward · · Score: -1, Flamebait

      This isn't flamebait. He's absolutely right! The best approach for this guy is to sit the fuck down and start typing everything down. Don't worry about formating, spelling, grammar, paragraphs, ANYTHING. Type it all out as fast as you can then start editing. The article submitter is an asshat.

  2. easy by nri · · Score: 0, Flamebait

    its quite obvious really. Take the customer requirement spec that you already wrote, take functional specification that you would aready have written, take the design note document that you aready wrote before you started coding and possibly take some of the fully documented comments from the header files for the functions. Easy right. Unless you are one of those hacker that dives straight in without proper design.

    --
    if :w! doesn't work, try :!cvs commit -m""
  3. Re:Basic technical skills by KDan · · Score: 0, Flamebait

    Yeah, that's how you end up with an application that looks like one big hack.

    Daniel

    --
    Carpe Diem