I have let this blog sit for too long. I am going to attempt to write about the frustrations of development and ways they can be resolved. My first series will be about methodology. A word more foul than workflow. Both words used by those who think all problems can be solved by the wave of a WYSIWIG wand.

Methodologies can make or break a project, a team and companies. I view them, as many do, as effective ways to kill a project. The issue is most development methodologies require heavy paperwork. Often times resulting in long expensive meetings to produce documentation which ends up being more expensive than most realize. Nothing kills a project quicker than paying for large groups of people reading to each other. Money and precious time quickly become an issue if you design an enterprise service before you implement it.

Developing applications can be unpredictable. The issue is, some stakeholders want to think it is. The only way I have ever know a development effort to be successful is to keep it small to start, and grow it over time. Success on a project should never be measured by how many buffalo it can kill by a due date, rather by its small incremental accomplishments. The best analogy I can think of is, you can dream about what is at the other end but unless you start walking there it will always be a dream. Sometimes convincing all members of the team of this is more fight than it is worth.


start with test cases.

Everyone on the team needs to understand the true importance of this one simple item. JUnit or another testing tools can quickly prove their time and worth. It is an easy and effective way to create applications which manage themselves. This doesn't mean they don't need attention. More like having a good pet which has self control. Testing should be used not just to show the code works. It should show how it breaks also. A good test case should show people how to use the code you wrote. Think of it as teaching someone what it is the code does, ensuring they know when they misuse it.

Establishing a sync, test and if its green, release process.

This sounds simple however, for people are unaccustomed to using a Complete JUnit testing environment this can become an issue, fast. This process is comparable to a math equation. You have to be diligent to follow the process or you get the problem wrong. The order of operation is just as important as the execution of each step. Just because you only made a small change to the code you are working on, does not mean you didn't cause issues on a larger scale.

Each person is responsible for taking turns syncing, running and fixing all test which are broke, releasing code which is completely clean and tested. When everyone does their part by following good testing practices, taking solid steps forward quickly reveals a solid product.

Monitoring the project code base can not be trusted to JUnit alone. Two of them I have found to be very useful are Emma and SoapUI. Emma is wonderful for keeping a close eye on the code base. If you use an IDE like Eclipse, you can use both of these tools as plugins.

Running JUnit tests as code coverage gives very accurate percentage reports showing which classes need more testing. However, to my knowledge, it doesn't catch positive and negative situations for testing coverage. The feature of highlighting untested lines of code makes it quick to view areas of concern.

SoapUI has a nice feature of creating xml files containing testing information. I have become accustom to creating a SoapUI project in the Java view. From here you can sync it with a repository for sharing with others. The application I am currently working on uses SOAP messages as an interface. With SoapUI I can create tests containing test data which can be reused. Both tools are defiantly worth looking into.

Everyone on the team needs to pick a technology

This is not done to pigeon hole anyone but to bring the team up to speed on it quickly. This is a time to learn and offer the ability to create a passion for the technology. Once an individual of the team is ready they should then educate the team with what they found, how it works and give a plus minus analysis to the group. Above all everyone needs to have an open mind to learn everything they don't know and teach everything they know.

I will continue this soon.