Software Development Best Practices

From Jonathan Gardner's Tech Wiki
Jump to: navigation, search

Introduction

There are as many opinions on software development as there are developers. Perhaps there are even more opinions than developers. Regardless, here's my opinion on how software should be developed.

Team Organization

There should be three teams.

Development Team

This is the team responsible for writing new code, fixing bugs, and documenting the system. They also write unit tests and manage a common development environment.

Release Team

The release team is responsible for managing the release cycle, which includes gathering all the code changes, building the release deployment, running the software through the test cycle, and putting the software into production. The release team manages any software to handle releases.

Testing Team

The testing team is responsible for writing and maintaining the testing software. They run the most recent release through the testing cycle before giving the thumbs up. If there are any bugs, they document it and report it to the developers. The test team manages the bug reporting and tracking software.

Project Based Organization

Each development, release, and testing team is responsible for one or a handful of software projects. Their systems are highly specialized for that particular piece of software. The members are also intimately familiar with the software and the issues surrounding the software.


Team Management

The team is organized into a group or peer engineers, and one senior engineer. There may also be a project manager or two who are responsible for tracking all the work of the engineers and helping upper management understand the progress of the team.

Development Lifecycle

The development lifecycle is more of a waterfall process. However, the tasks are generally small and progress should be readily apparent.

The steps in a task are:

  1. Define the task's goals.
  2. Define the task's design.
  3. Implement the design.
  4. Test the implementation.
  5. Release the implementation.

Note that defining tghe task's goals or design doesn't necessarily culminate in a formal document. Usually, these designs can be sketched on a napkin or expressed in a few paragraphs. However, that doesn't mean the task's goals or design should be uncertain or vague.

Implementing the design includes writing unit tests, writing the code, and passing all of the unit tests without breaking any other unit test.

Once the implementation is complete, and all the unit tests passed, then the code's responsibility transfers to the release team. They guide the software through testing. Any bugs found in testing should be resolved by the developers. Then the software is released.

Developer Tasks

Developer's tasks shift between the following:

  • Defining task goals.
  • Defining tasks designs.
  • Implementing designs (writing unit tests, code, and testing, resolving any issues that arise.)
  • Resolving bugs.

Most of the developer's time is spent learning and researching and understanding their customers. If most of the developer's time is spent coding, then they are probably a bad coder. (They should be automating the task of coding by writing good libraries that are useful.)

Tester Tasks

Tester tasks shift between the following:

  • Testing software.
  • Writing software to test the software.
  • Documenting bugs.
  • Verifying that bugs are fixed.
  • Inventing new tests to find new bugs or to make sure old bugs don't reappear.

Some companies treat testers as the "final gateway" before release of the software. This is not the right view. The developers should own their code from conception to launch and then some. Testers help developers in the complicated task of ensuring their software works. It is always a good idea to get a different set of eyeballs and ideas in for sanity's sake.

Release Engineer Tasks

The release engineer tasks revolve around the following:

  • Integrating implemented tasks. If two tasks conflict, then it is a bug that the developers need to resolve.
  • Putting together a release for the testers to test agains.
  • Releasing the software.
  • Monitoring the software.