In Response to Matt Raible’s question about my preferred development stack.
Source control
In my own development project I switched to Git some time ago. I was using svn and before that cvs for a couple of years. Git just makes it easy to try out small ideas very quickly without reverting the code. We will introduce Git at work pretty soon (I hope).
The Atlassian cloud
I was using Confluence as a Wiki in my open source project and my current employer Hypoport uses it as well. Bug tracking is pretty much a task of Jira. Those two integrate very nicely. You can have ping backs in your Jira Ticket from Confluence, so you see all related files. I would love to use FishEye but I’m not sure how to justify the costs and what the added value is in our case.
The Code
I’m pretty much sold to Jetbrains IntelliJ Idea. I’m using it for 5 years now. With it comes Teamcity. It’s a very nice continuous integration tool where the biggest plus (among other things) is the delayed (and pre tested) checkin. No more late night checkins which break the master. We just rolled out the latest version which has a much nicer Git integration (so we can make the switch).
So it comes down to:
The List
- Source control: Git
- Wiki: Atlassian Confluence
- Continuous Integration: Jetbrains Teamcity
- Bugtracker: Atlassian Jira
We are about to use Sonar for code analysis and development over time, but this is just in the beginning.
What’s yours ?
What is Extreme visibility?
Extreme visibility is all about providing information about the code to every team in near real time. We show several metrics such as complexity of the code (xs), todo’s, deprecated methods, number of broken builds, open tickets and their priority and so on. These are distributed over a couple of screens which our software is rotating through. Every team member can easily see if his or her commits effecting the code quality in a good or bad way and makes the members aware of certain quality standards we try to keep in our code base. A typical screen looks like this (mockup):
Extreme Visibility
We discovered that showing these kind of statistics to the team has the effect that everybody in the team room cares about the numbers (and therefore the code quality). Without this display you just don’t know how your changes will effect the overall quality of the code. It might seem a bit threatening to individual team members at first (like we do show who checks in without a commit message) it turns out this is not really a problem.
While we did provide very detailed information in the past about the trunk and every branch (every user story is on it’s on branch), we found out that too many screens are counter productive and results in not caring about the values displayed too much anymore. We also do believe that showing time line and progression information on several metrics are very motivating to the team. We are planning of tweaking the information this way in the near future.
The software we use is written by ourselves in Grails. On the front end we simply have Firefox running a full screen mode. Every team has a big screen TV connected to a computer (turns out I could connect my Sega Dreamcast too). We did collect some good feedback and learned a lot about the usage in the last couple of months. The next step now is to enable the teams to write their own modules to provide the information which is the most useful to them.
I’m not aware of any open source (or other) software doing the same kind of thing. Writing it by ourselves we could tailor it to our specific needs like showing svn information, showing Teamcity build statistics or information about the code using Structure 101.
Overall the team I’m working in is very happy with the information we get from our extreme visibility monitor. XV makes sure we all can see how the quality of our code develops and we get warning signs to take counter measures to bring it back on track. And that’s what we want after all 
.
