Documentation - is it an assumed part of the job? [closed]

Question

So I was told from higher-ups that a software engineer that left the company didn't document his processes and he should have as part of his duties. My gut reaction was to say - "you don't get what you don't ask for", this is more a project management issue. The estimates given were to "develop a working piece of software", and there was never any discussion about documentation.

Is it fair to assume that each and every developer should be responsible for creating documentation even when it is not explicitly mentioned as a deliverable?

Answer 1

A software developers job is not simply to write software that works but to write software which works and is maintainable.

Different organisations and people may have different views on what maintainable means but if you are part of a company that considers maintainability to be highly documented, fully unit tested code then your job is to write software which works, is highly documented (to your companies required standard) and fully unit tested.
That's what they hired you for, not to develop code in your own personal way.

If specific processes are required to make your work transferable to others then it's within reason that a company should expect you to document them. Otherwise, how will they cope with you being getting sick, or hit by a bus? for example.

Answer 2

The answer to your question is company specific. I would have told you to check with your management, except that your management already told you point-blank.

There are many forms of documentation - documentation through Test Driven Development (TDD), formal documentation, comments, documentation through code, etc. You have to nail down with your management the type of documentation they are looking for and the style of this documentation. you don't get away with documenting any way you want.

Answer 3

It depends.

If the software is being released as an API for other programmers to use (even internally), there should be some manner of documentation/user-guide provided. That might not be formal documentation. It might just be an email with some example code. But that sort of customer support is necessary since the code is the product in that case.

Otherwise, if the people involved (or the industry itself) are older, then the expectation of documentation is fair.

Before the advent of the agile development methodology, formal documentation was a key part of the process. More formal industries (medical, banking, government) or industries that move more slowly (manufacturing for example) still make use of documentation. Also, people who learned about software development back before agile might expect documentation to be par for the course.

But for almost everyone else, they should be familiar with modern software development practices that tend to eschew documentation. It is unreasonable to assume that the developer will produce documentation without prompting.

Though, as you say, it is pretty trivial to explicitly include that as a requirement. When in doubt, communicate.