While studying the book of Software Engineering by author Roger Pressman I came across this point about software reengineering , where it is written in the book that if creating documentation is time consuming then it is skipped. Roger Pressman says if there are no significant changes after reengineering then documentation creation is skipped. But if we take example of 'javadoc' and if the javadoc creators just skip the documentation restructuring while new release of java version, just because there is no major change it could be disastrous for the 'javadoc' user. I am confused if this software engineering practice is practical. Can anybody ellaborate and help me understand what Roger Pressman expects here.
Documentation is more than reference documentation. Keeping Javadoc- or Doxygen-style references up to date is fairly easy because they are written right next to the code.
A lot of documentation lives in completely separate documents. For example, end-user software may have a manual. There may also be internal documents, like architecture overviews, UML diagrams, change request documents, or audit reports.
All of these documents have value. But their value does not always outweigh the cost of updating them after each change. E.g. doing an audit may be very costly, but it may be possible to skip it for minor changes. If the architecture was not changed significantly, there's no need to redo all diagrams. It depends on the chosen development process, on the business priorities, and on the regulatory context which documents need to be updated.
Staying with your Java SDK example, there's not just the Javadoc documentation. The SDK also contains extensive guides and tutorials for specific parts of the language and standard library, e.g. a guide through available Swing GUI widgets. It is likely not necessary to update these for each Java release because the library and the language mostly stay the same.