Whenever we develop a module we always run it once locally to test whether it is working and then hand it over to QA. This test can be either manual or automated, if it is manual it means that you are spending some effort to test. Given that you touch a module at least a few times (due to bug fixes, change of requirements) you are spending a multiplier of the initial manual testing effort.

The better approach is to write a unit test case. From what I have seen people don't do this. They are okay with manually testing the code and this is mainly due to

  1. Instant gratification, you are able to test the code quickly and get it out, you don't want to spend that little extra effort in writing the unit tests
  2. As humans we don't compute the long term gain but see the short term wins, which might have helped in forests when there was a tiger right ahead of us but in coding it is important to keep in mind both the short term and the long term
The second bit is documentation, again I have seen people bypass this step with time as a reason but that is definitely not a reason because the time spent on friendly chats can go into writing proper documentation, or as explained in the previous posts have a backbone and standup for documentation during the project planning phase.

Documentation should be
  • Simple but not simpler
  • Covers high level design
  • Low level pieces should get auto documented with code
  • There should be a good way to generate documentation with your code
  • Code review should include documentation as a concern
Javadoc is a really good way to generate documentation. There are plugins for maven which allow you to publish Java docs directly on to Github Pages which you can then share with your org. If your project is configured for git, your remote git supports the concept of github pages then the following steps will let you push the documentation on to Github Pages directly.

git checkout --orphan gh-pages
git rm -rf .
cat "placeholder" >index.html
git add index.html
git commit -am "initial pages commit"
git push origin gh-pages

Add the following into your pom.xml build > plugins section

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <version>2.9.1</version>
    <configuration>
        <aggregate>true</aggregate>
        <show>public</show>
        <nohelp>true</nohelp>
        <header>jTransfo, ${project.version}</header>
        <footer>jTransfo, ${project.version}</footer>
        <doctitle>jTransfo, ${project.version}</doctitle>
        <links>
            <link>http://static.springsource.org/spring/docs/3.0.x/javadoc-api/</link>
        </links>
    </configuration>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-scm-publish-plugin</artifactId>
    <version>1.0-beta-2</version>
    <configuration>
        <checkoutDirectory>${project.build.directory}/scmpublish</checkoutDirectory>
        <checkinComment>Publishing javadoc for ${project.artifactId}:${project.version}</checkinComment>
        <content>${project.reporting.outputDirectory}/apidocs</content>
        <skipDeletedFiles>true</skipDeletedFiles>
        <pubScmUrl>scm:git:git@github.com:joachimvda/jtransfo.git</pubScmUrl>
        <scmBranch>gh-pages</scmBranch> <!-- branch with static site -->
    </configuration>
</plugin>  

To publish javadoc onto github use

mvn clean javadoc:javadoc scm-publish:publish-scm 

Taken from here.

I am using this in all my newer Java projects. The benefit it gives me is two fold
  1. I can quickly go through the Javadoc to get the purpose of a class, method etc..
  2. Others who are going to extend the code can do the same
Missing out on either Unit Tests and Documentation have a long term impact on a project. My heuristic is that any code that lasts a few weeks don't need all these but projects that have a life time longer than that where multiple people are working on it definitely need all these things for lower bugs and quicker development to happen.