How much time should a developer spend on coding versus testing versus writing various forms of documentation? I checked on-line to see what others thought and found plenty of coding versus test writing figures (such as this). Many estimated the code to test writing ratio at 1 to 1. Oddly I could not find any of these informal metrics that included documentation. So, I’ll offer my own.
It depends, of course, on the type of software being writing. Let’s assume that the software is a user facing application. In that case I think a ratio of: 40% on documentation, 40% on tests, and 20% coding is about right. Documentation includes code comments, log comments, API documentation, user manuals, and so on. Tests include unit tests, functional tests, and others. Coding is that thing you do to make your tests pass.
Rather than focus on cool hacks, I’d like to see developers (especially open source developers) focus on quality. The ratio I mention above is focused on quality. Cool hacks are about the programmer, quality is about others. Quality software runs reliably for others because it is well tested. Quality software is easy for others to use because it is well documented. Great software is quality software. Great programmers write quality software.
On a humorous note, while searching for metrics I came across the wonderful Tao of Programming and found this passage:
A novice asked the Master: “Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?”
The Master replies: “That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.”