Random Thoughts on Software

I was talking to a friend who works for Trilogy Software in Austin, TX, and he was describing their model for developing software in developing nations (no pun intended). Apparently, they save a considerable amount of money over hiring U.S. workers, which is what attracts most people to try utilizing the workforce in developing nations. In addition to saving money they are highly successful in delivering quality/timely code to their customers, which seems to be rare among the companies that try utilizing foreign developers.

Here are some of the main points of their model, as it was described to me:

* Hire the most talented people (top graduates from the top universities, the most seasoned/talented developers, etc.)

* Focus on countries that have a large, English-speaking workforce (mainly India)

* Pay employees a much higher salary compared to others in their country so that it is very unappealing for them to leave and go to another company (retention)

* Have short development cycles (1 month iterations)

* Have a strong group of business analysts (with tech savvy) who collect the requirements for each iteration, and then bring them back to the development team (a.k.a. ambassadors)

* Have a very extensive QA cycle that is led by the business analysts who gathered the requirements (lags development by about 1 month)

I’ve found that it is difficult to push XP style unit testing when you are first introducing unit testing into a team that is not test infected, whether the developers are experienced or not. The best approach I’ve found is to introduce unit testing incrementally.

First introduce the process necessary to acheive continuous integration with unit testing:

• No non-compiling code should ever be checked into the repository

• All unit tests should pass before and after synchronizing with the repository

• All the tests should be run recursively under the src directory to avoid orphaned tests

Then introduce the fundamental best practices of writing unit tests:

• Unit tests should run in isolation (no external dependencies)

• Unit tests should run individually (they don’t depend on state that is setup in other unit tests)

• Unit tests should run fast

• Non unit-tests should be kept separate. All subsystem or acceptance tests should go in a separate source structure and perhaps have a different execution frequency.

Then introduce the extreme aspects of unit testing:

• Unit tests should be written first

• No code should be committed to the repository without unit tests

Related:

JUnit best practices

JavaUnitBestPractices

junit.org

testdriven.com