To document or not to document?!

To document or not to document?!

Introduction

Documentation is a very important facet of any software development phase, it is a way of communication and ensurement of common understanding.

Just imagine an enterprise solution with over 40 - 50 team member working together without any proper documentation, the result may lead to failure of delivery or client dissatisfaction. However, over- documentation may lead to the same outcome as well.

No one enjoys it

Documentation is a very cumbersome task and waste a lot of effort into writing, reviewing and source controlling it.  Consequently, delivering a lot of documents with no significance may be an overhead to the project.

Documents should be as few as you can and as concise as possible. Sometimes long unreadable documentation is as helpless as no documentation at all, and I have been through both.

What to document

Everything that needs to be shared across the team, things that needs to be communicated to ensure common understanding and proper implementation. Examples may be:

  • Design and Coding Guidelines written in a simple and clear format.
  • Design Decisions taken, to prevent future arguments.
  • Minutes of the meeting to ensure mutual understanding and to track actions.

In general document what can be very useful.  You can ask the opinion of the team to double check if any document is useful or not.

What not to document

Some other documents might not be as helpful as they may appear, like:

  • Long architecture documents, just keep them simple and to the point.
  • Detailed design documents, details should be entrusted in the code. Well commented code is far more helpful than long documents.

Conclusion

I have been through projects that documentation is simply for the sake of documentation, and believe me people write these ones just to get rid of the tasks assigned to them. These kind of documentation not only is a waste of time, but also were misleading to anyone reading them.

In today's business, change is inevitable and code changes regularly as well as decisions taken. Carefully select the documents that you really need and make them as simple as you can.

Documents currency is important as well as accuracy & expression. Being concise helps a lot to acheive currency

回复

要查看或添加评论,请登录

Emad Elagouz的更多文章

  • Where to Store your Business Process Data

    Where to Store your Business Process Data

    Introduction Saving your business data in your own system of records (SoR) rather than depending on the process DB is…

    4 条评论
  • IBM BPM 7.5.2 vs 8.5.6

    IBM BPM 7.5.2 vs 8.5.6

    Introduction I have experience designing and implementing business process with both versions, although it is mentioned…

    2 条评论
  • Process portal login page customization step-by-step

    Process portal login page customization step-by-step

    I tried to simplify the steps to customize your default login page as musch as possible. Please follow the below steps…

    2 条评论
  • 5 Things to do before start BPM standard development

    5 Things to do before start BPM standard development

    Introduction I have a long history with IBM BPM products, starting when there were only one version of process server…

    1 条评论
  • IBM BPM’s new Human Service - Pros & Cons

    IBM BPM’s new Human Service - Pros & Cons

    Introduction The new Client Side Human Service (CSHS) that was introduced in the new version of IBM BPM standard 8.5.

    8 条评论
  • IBM Integration Bus and BPM Intersection

    IBM Integration Bus and BPM Intersection

    Introduction Many times, you face the problem where the customer has the IBM middleware full stack or more than one…

    16 条评论

社区洞察

其他会员也浏览了