Five years ago, I started a new job and encountered the JIRA bug tracking system, after having been subject to pathetic bug tracking systems at previous companies. JIRA knocked their socks off in terms of ease-of-use and multi-platform support (it runs in a web browser). I’ve been a pleased JIRA user ever since. Recently, I stumbled on this article about what’s new in some of the best quality bug tracking systems on the market.
Bug (issue) tracking systems have become a standard tool for any organization that develops software and have evolved greatly in the last years. InfoQ has conducted a virtual panel with people from JIRA, FogBugz, Basecamp and MantisBT about this evolution and the future developments in this field.
The virtual panel discusses integration with IDEs, project planning, story-boarding, and social networking integration.
Here’s an article that I think is worth reading. It details how the Open Invention Network (OIN) keeps open source software safe from patent threats. It also explains about patent troll companies and their financial motives. It sounds like it’s worthwhile for companies that rely on OSS to become affiliated with OIN.
Bergelt described Microsoft’s patent suit against TomTom as being a part of the software giant’s “totem strategy”. By getting various companies to settle patent suits over particular patents, Microsoft can erect (virtual) totem poles in Redmond, creating a “presumption of patent relevance”. According to Bergelt, Microsoft tends to attack those who try to create parity with it in some area, which TomTom did…. But, Microsoft was surprised to find that TomTom had allies in the form of OIN and others. Originally, Microsoft had asked for an “astronomical” sum to settle the suit, but after TomTom joined OIN and countersued Microsoft, the settlement number became much smaller.
OIN was started by six companies: Sony, IBM, NEC, Red Hat, Philips, and Novell.
I tend to wonder about the “best” technologies for a given problem. Recently, I’ve wondered why Wicket is reportedly better than Java Server Faces (though I’m using neither). Perhaps it’s human nature to look for the Next Big Thing or for silver bullet solutions that supposedly increase productivity while offering robust features.
Here’s a blog post that ponders whether a new framework or a programming language can really offer better productivity benefits over an ocean full of alternatives. The author asserts that the real time cost on a project is not in writing code, but in the following activities:
- Understanding preexisting code
Tools or languages that make any of those activities easier are to be coveted. Java refactoring tools outshine those available for Grails. Java is easier to read and comprehend than terse bash scripting. Some frameworks/platforms make debugging easier than others.