Technical document

Hi Expert,
Technical Documentation is writing before development/Project start or after completed the project?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Darrell PorterEnterprise Business Process ArchitectCommented:
The process of Technical Documentation is generally begun at project inception and continues through project completion, becoming more refined and coherent as the project approaches completion.  The project should not officially be closed until Technical Documentation is complete.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Ryan ChongSoftware Team LeadCommented:
Technical Documentation is writing before development/Project start or after completed the project
Technical documentation can be written during the process of development and review during the development life cycle.

In common, the release of the technical documents would be around the project deployment period, but this need to be confirmed, negotiated, planned and agreed with your client. You also need to do scoping on what areas to be covered in your various techical documents, and try to capture the details as clear as possible.
bbaoIT ConsultantCommented:
can we know what's your ultimate point to ask this question? i guess that would let us address your concern specifically rather talking about technical document in general.

FYI - in actual projects, changes always happen hence technical documentation needs to be updated in a practical way as per business needs and rules.
There is quite old approach called "literate programming" (Donald Knuth, The idea is to write documentation in the form the narrative text with snippets of the real code. Then the tool is used to extract and reorganize the code snippets from that narrative source files into the code source files that are later compiled.

In my opinion, it may fit to some brains. It definitely worked for Donald Knuth. Anyway, I am not sure if it works for project under time pressure with many people in the team.

The alternative approach is to write "narrative comments" to the source code, and then to use a tool to extract and reorganize the comments. In my opinion, this approach is more successful in real environment.

The key idea is to keep the code and the documentation as closely bound together as possible. It must be extremely easy to locate the part of the documentation and the related part of the implementation code.

As there may be more people that will share the same files, you need some decent Version Control System. (Learn Git, if you can choose. You cannot go wrong.)
lankapalaAuthor Commented:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.