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?"

2 of 55 comments (clear)

  1. 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""
  2. 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