The Top 12 Productivity Killers in Your Development Methodology

Find out what the 12 most troublesome facts of development are, and learn how they can affect efficiency.

Fact 1: Maintenance cost is the biggest enemy of efficiency.

Fact 2: Developers don't like to test, and they don't test their code the way they should.

Fact 3: When a bug is discovered, it takes much more time to isolate it than to correct it.

Fact 4: It takes time for a developer to switch from one project to another.

Fact 5: Bugs increase as the number of developers increases.

Fact 6: Tests have several layers.
Writing good tests is a tough challenge. For example, writing unit tests on existing code is very difficult, and they cannot test everything. Functional (QA) tests are powerful for challenging your application, but they usually run slowly and fail to give enough information about the cause of the problem.
So you must divide and conquer. Running huge tests is useless if the fast ones do not pass. Create test layers from the simplest to the most complex:
* Level 0: Unit tests on the developer's own environment
* Level 1: Unit tests on a build server, started on (almost each) commit
* Level 2.1: Integration tests, where you try to have several modules connected together (You replace the mock objects with the actual modules you created. For instance, you would use an actual XML parser instead of a mock one.)
* Level 2.2: Integration tests, with access to the system (socket, disk, etc.) (Here you can test the actual access to the system.)
* Level 3: Functional tests, where you test the visible part of your application (actual functionalities seen by the user) (This layer is certainly not enough.)
* Level 4: Performance tests
* Level 5: Customer use (OK, this is not a test layer, but it certainly is a source of surprising new bugs.)
You need to start the more complex tests only if the simple ones pass.
The motto of this methodology is a bug should never appear twice. Therefore, for every bug you find, you should create a test that guarantees that it will never happen again. Sometimes the test is a unit test (which is better), sometimes it is an integration test.
The sooner you get the error, the sooner you correct the issue. So you'd better begin running tests at Level 0 rather than Level 3, and the code quality tends to increase naturally with the number of tests.

Fact 7: You must have a restricted number of languages.

Fact 8: Tracking change and innovation is necessary but difficult.

Fact 9: To stay productive, a developer must not switch activities too often.

Fact 10: Defining the architecture is as important as coding.

Fact 11: Developers have different priorities than product owners do.

Fact 12: Coding conventions are efficient; they must be imposed.