Skip to main content

Software Development in Troubled Times

Posted by johnsmart on October 21, 2008 at 9:36 AM PDT

Nowadays, more than ever, developers need to be productive. Ultra-productive. Organizations need to optimize the added value they get out of their development projects, and should be actively looking for ways to do it.

Of course, you can adopt the traditional approach - work harder. 16H work-days, no weekends, to smooth over unforeseen complications in your project. But wouldn't be better just to work a little smarter instead?

The development process is one area where many organizations stand to gain a lot by investing relatively little effort into introducing some new practices, and improving existing ones. There are generally many areas where things can be improved, but here are a few simple tips to streamline your development process, just to get you started.

Rethink your CI notification strategy

By far the most common CI notification mechanism is ye old mail server. However, are you sure that email is the most suited system for the task at hand? Try using instant messaging rather than (or as well as) email for your CI notifications. Remember, email tends to be a distraction - you will be much more productive if you only consult your emails every couple of hours or so. Email was Or, at least for build failures - people need to know about this fast.

Aggressively optimize your build process

Build metrics are a great way to monitor the health of your build process. Why has the code coverage been dropping off over the last 3 weeks? Why is the number of unit tests not increasing at a regular rate? And why did that build take so long to fix? How long do your unit tests take to run - and are there any that are taking too long? This sort of information is not a luxury - it should play a key role in the ongoing task of keeping your build process fine tuned. Modern CI tools such as Hudson, Bamboo and TeamCity display ample statistics about your builds. Bamboo in particular does a great job in this respect. Whatever CI tool you are using, learn how to get the most out of its reporting features, and use them to identify and fix trouble spots in your development process. And if your CI tool doesn't give you all the information you require? Then find one that does!

Streamline your release process

During the release process, there are many book-keeping tasks such as preparing release notes, identifying which issues have been resolved in a given release, tagging versions and so forth. These are an important part of the software life cycle, and if you neglect them, the QA guys and the end user may become irate. However, automate these tasks as much as possible. Many CI tools integrate nicely with the principle issue tracking systems such as JIRA and Trac, so that you can view what issues where fixed in a particular build based on the version control logs. If you are using Eclipse, Mylyn can help you group work on issues into logical change sets, and proposes a standard template listing the resolved (or just impacted) issues for a particular piece of work. Or you could simply use Subversion hooks to ensure that each Subversion commit referred to a valid issue number.

These are just a few ideas - there are plenty more. The bottom line is - you don't have to tolerate a sub-optimal development process - rather, get in there and do something about it. Good luck!

"One of the best and most useful courses I have attended...Best development course I have been on in a very long time...A 'must' course for serious Java developers..." - Read what people are saying about the Java Power Tools Bootcamps.

Comments

We currently have CruiseControl configured to achieve the same affect - also very simple to configure etc. However, one shortcoming in CruiseControl is that the transitive dependency checking fails for complex multi-module Maven projects. For example, Project A is a multi-module project with a parent pom and then a sub-pom for each sub-module. Project A depends on Project B. When Project B builds, Project A will only be built if the parent pom in Project A depends on Project B. If any of the sub-modules of Project A depend on Project B they are ignored/not discovered and no build happens. Any chance Hudson can handle this situation?

Yes, Hudson has excellent Maven 2 support, and understands Maven 2 dependencies in all their intricacies. I discuss this in another blog entry ("Managing automated build dependencies with Maven and Hudson" - http://weblogs.java.net/blog/johnsmart/archive/2008/11/managing_automa.html) - you might want to have a read for more details.