If you remember I work for Programeter and I thought I should talk about it this time. Programeter is a monitoring and reporting tool for all kind of managers in software projects. It is both for technical leads and for managers without IT education. It helps them to keep an eye on software project in real-time.  When we started to work on Programeter, our key goal was to make it autometed same way as Google Analytics is. We wanted to make sure that niether of project members should spend time on manually submiting data. Instead Programeter collects all the data from your development environment by connecting to code repository, bug tracking and task tracking systems which you already use.

How It Works

There are four types of reports or so called angles: Effort, Scope, Quality Assurance and Knowledge. The reports in the Effort angle focus on how much effort and activities has been done by project team. For example, you can compare how active is team on different days of the week. You can see how completed tasks affect number of new bugs on daily basis. The information in Scope angle can help you to understand how your project moves towards its end. The reports in Quality Assurance angle focus on comparing the information about quality of code based on indicators received from different types of development tools. Knowledge angle reports focus exclusively on programming team’s knowledge. For example you can see when project knowledge is poorly shared and take proactive actions to lower team attrition risks.

Programeter is all about metrics and indicators. My favorite one  is “know-how score” of developer. It illustrates the breadth of the individual developer’s knowledge in the project. For example, the know-how score of 6.5 in certain project, means that developer is capable of working alone with most project components. There are also software project indicators like: Team Activity, Team Friendliness, Contribution Size, Contribution Efficiency, Project Code Stability.

I hope it all didn’t sound as advertisement…actually, I know it did. But we truly addicted to what we do here, so you have to excuse me And please, if you you or your company is working on tools for software development, please let me know. I would be glad to review it and comment about it on my blog.

This week I wanted to give an overview about one of the most popular and on my opinion one of the best code repository hosting services CVSDude. CVSDude is an old player in hosted repositories game – it was founded back in 2002. It has more than 60,000 users in more than 100 countries worldwide, making it more than a reliable service provider.

Probably, the first question you would have…why the hell I would need move my repository to external service provider? I see following reasons: you want to save on infra costs, you have distributed team , you don’t know how  to administer the repo or you are just lazy.

Before you move your repo, you have to think about security. If you are paranoid about security, probably hosting the code repository is not for you. Personally, I think hosting the repo makes sense if:

• you understand that professional admins at service provider has better chance to stand against attacks compared to you.
• you are running an open source project
• you are running a small company or project that is more concerned about costs than about hypothetical risks of loosing your data

What else is cool about CVSDude is their pricing. You can start using it at $7 a month. If you do repository installation yoursleft,  I don’t think you can beat this price. Of course, unless you don’t value your time at all.

Last year CVSDude has launched new version of their platform. With this new version you can also host task and bug tracking systems at their servers. TRAC and Bugzilla are supported.  It makes CVSDude truly a good place for startups and small projects willing to start coding at day one.

What I miss at CVSDude is probably some important pieces of our development environment like: continuous integration tool like CruiseControl and of course integration with Programeter developed by my company.

Few months age  we have started to use UserVoice at our software team. This online tool is a customer feedback forum with voting functionality. As they describe it themselves it adds structure to feedback and reduces the overhead of an honest dialog with users. And I agree – some smart features make this simple forum solution very powerful for those who work on software products.

What makes this tool very powerful is the voting functionality. Every user has 10 votes he can assign to any available feature requests or to new ones. Simple. This makes user think about what is most important for him and not to write generic comments into the forum.

Initial idea for us was to use UserVoice as a feedback engine for our website visitors and application users. We expected to get general comments, like you get on blog posts or news announcements. Something like: “wow, your tool is gr8″, “waste of time”, “where can I find more info on…”. What has surprised us is that structure of the UserVoice forum made users to submit feature requests instead of expected general feedback. We have got request like “Integration with JIRA” (done), “create free plan for small teams” (done), “Special functionality for Open Source projects” (in progress). All of those were feature requests.

To UserVoice team I wanted to give thumbs up, and request one change. I think, your feedback widget is wrong. It doesn’t unleash the power of the tool as it suggest your solution is to give unstructured feedback. I would expect default widget to be “Suggest New Feature” or “Vote for Next Feature”. This would differentiate you from similar user community tool GetSatisfaction, which I hope to cover in one of the future posts

To conclude, voting functionality of UserVoice makes it well suited to engage user community to submit feature requests and gives each of your users a chance to influence product development. Don’t forget to try it “at home”.

Question which is bothering me for some time is whether you should have one tool for bug tracking and another one for feature/story planning? Or should you keep bugs and features in one system.

I think the root cause of this issue lies in misunderstanding of  ”bug” and “feature” concepts. End users and software developers look at the same things from so different angles that it is almost impossible to have common view. Old popular comics below illustrates this issue pretty well.

Bug vs Feature

Lets first take a look from end user point of view. There should always be the way for user to register his ideas or issues with using the developed system. So what you do, you give him/her  access to your issue tracking. If you are running software product company this could be customer forum or community site like GetSatisfaction or UserVoice, where users shout their opinions without risk to be punished.

So far so good. Now software developer gets into the same system and the fight begins. Argues, whether this issue is a bug or feature, is taking off. Users start pushing to put bug fixes into current iteration, developers fight back by calling issues the features and asking to leave those out of the scope. I guess it sounds familiar.

That is why I think it is healthy to keep bug/issue tracking separate from your project planning. Also you can call me psycho, but emotional aspect is very important here. My point: don’t hold dreams (read: features requests) together with problems (read: bugs). When you do release planning it kills the whole motivation of the team when you see that there are 5 times more bugs than new features planned. We, development teams,  like to do something new and not just fix the bugs.

Key goal of bug tracking system is to communicate with customer, understand his point of view, document the issue as much as it is needed and then pass it over to development team. Development team can treat this issue in the plan as new functionality. Call it feature, if it makes you happy. It doesn’t matter.

There are also different styles of using bug and task tracking depending on your company/project time. Software product companies that don’t have direct contact with end user can live with one system with no problem.Though, if you are a service provider and all of your project are done for external customers separate bug tracking is almost the must. From my experience in different types of software projects, I like having separate bug tracking anyway. It makes person responsible for tracking bugs to think like a customer, even you don’t have one participating in the project.

Key concept and functionality can be described in few sentences. You basically have 2 columns view: 1. Current iteration; 2. Backlog. Each story is a row in the column. Planning is done by dragging story from one column to another or to reorder the priority. Brilliant.

Important to mention that PivotalTracker has no concept of deadlines. This is powerful. When using this tool you truly have to think iterations, instead of tasks with deadlines. It forces you to be iterative not only on paper.

What I miss from this tool is the notion of “feature”. I would like to group my stories into features and do some feature planning inside the tool. Something similar to AgileBuddy.com. This would be extremely useful for product development companies, like ours.

Being developed by PivotalLabs, software development service company, PivotalTracker is their side-project. I don’t know if it a business for them. You would be surprised not to find any pricing information. But, quality and maturity of the product is great. We have used that for half a year and didn’t have any issues.

I hope the authors of PivotalTracker would create a similar bug tracking solution one day.