In a recent PDC2008 contest developers showed off their projects supposed to make Visual Studio better and more convenient to work with.

A few links to PDC2008 ShowOff Entries:

Multi-channel Virtual Earth - a multi-channel version of the Virtual Earth control.

Clipboard History for Visual Studio - Also demonstrates a 12-part blog series with complete step-by-step instructions showing how to build this feature for Visual Studio 2008.

Of course, Brian the Build Bunny won. I wouldn’t expect any less.

Duplicate source code? Inconsistencies in how it works? Well, here’s a tool that can solve these problems for you: Clone Detecrive for Visual Studio
is an open source tool that analyzes your source code and finds duplicates in it. The current release is limited to C#, but the team plans to adopt .Net, Visual basic and more. See their CodePlex page for more.

Just how automated is your work? Do you think you spend enough time on actually writting code, or maybe you could use some of that time you waste on solving technical problems?

How do you avoid the lengthy setup, infrastructure and management problems and leave enough time to deliver productivity? Here’s a list of some basic things that should be done for that purpose:

1- Source Code Control
2- Unit Testing and coverage
3- Continuous Integration and monitoring
4- Documentation (!!!)
6- Bug fix and source control integration
7- Logging software errors
8- Implementing database and its changes fast and automated
9- Test, UAT, release procedures
10- Communication procedures

For a detailed description of each step follow the link.

Can you believe this?

At Microsoft’s Tech•Ed North America 2008 Developers conference keynote delivered by Microsoft Corp. Chairman Bill Gates in front of more than 5,000 developers, it was announced the IBM and Microsoft are working together to allow the next major version of Visual Studio Team System Database Edition to be used to with IBM DB2.

Microsoft Corp. and IBM have announced that they are working together to increase productivity of IBM DB2 developers, to reduce risk of errors and to provide better backup and version control of DB2 database schemas. Together they are working to provide IBM DB2 database support for Visual Studio Team System. The IBM Database Schema Provider (DSP) for VSTS Database Edition will provide a DB2 Project system, versioned schema store and SQL Syntax Checking, allowing VSTS Database Edition to be used for offline development of IBM DB2 databases and SQL code, with differencing logic so developers can focus on the desired schema and allow VSTS Database Edition to generate change scripts. Together these capabilities not only improve efficiency and reduce errors that also allow greater teamwork as developers move towards VSTS Team Foundation Server to co-ordinate team activities.

What? Did I get this right? IBM DB2 compatible with VSTS? What, does IBM have too many users? Want to lose more to Microsoft? Sure =) Go Bill! =)

Check out Martin Woodward’s new build-assistant. The author has posted a video of his new invention, Brian the Build Bunny. The Bunny is wired up to Martin’s Team Foundation Server and keeps him updated on the success/failure of software builds.

Brian is a Nabaztag smart rabbit. He reads out details of check-ins and builds. If a build has failed then his ears go down to show how sad he feels, but if you fix the build his ears will soon pick up again.

The video in Martin’s post shows Brian the Build Bunny in action, check it out for a load of positive emotions! =)

“…it is pretty much a standard TFS event listener that then sends text to the rabbit using the Nabaztag API.”

Don’t you just love the way TFS is flexible enough to allow this?

How do you decrease the number of bugs in your software to the minimum? That’s the question that probably worries all code-writting folks out there. Considering that the issue of bugs can be pretty personal (that is, the bugs occuring in one developer’s work might not be likely to occur in the other’s and vice versa), it’s hard to come up with and outline the most important bug-decreasing tips.

But it’s worth trying, like Patrick Smacchia did over here. He lists his own seven ways to minimize number of bugs in the software.
The seven are:

Contract

The idea of contracts is to insert correctness information inside the code. When contract is violated it means that your code contains a bug somewhere…

Automatic test

…having a solid battery of automatic tests is an excellent way to decrease significantly the bug rate on tested code, but also to avoid new bugs when code gets refactored.

Empirical approach

* Most of bugs in a new version are coming from modified code and brand new code

* Unchanged code that works well for a long time in production won’t likely crash within the next release (what we call stable code).

Code review

…focus your review on not stable code, i.e added code and modified code. If you release new versions often, the mass of code to review before each release will quickly become an epsilon of the size of your entire code base. Doing so can also be seen as a way to capitalize on code reviews made during previous iterations.

Prioritizing bugs fix over new features development

This popular methodology directly results from the concept of stable code. Prioritizing bugs fix over new features development can be seen as a way to constantly struggle to maximize the surface of stable code in our code base.

Programming style and code quality

The recent buzz around LINQ or F# comes from the fact that object style programming is more bug-prone than functional style programming. This fact results from the expressiveness of functional style. In other words, functional code is easier to read and understand. A major aspect of the expressiveness of functional programming style is IMHO the concept of immutability that I described in a previous blog post Immutable types: understand their benefits and use them. That’s a fact, it is hard to write, understand and maintain code that mutates states at runtime (for example this is why global variables are so harmful). And this becomes much harder in concurrent environment.

Obviously, code quality has also a direct impact on code correctness. Anti pattern such as methods with high LOC, high Cyclomatic Complexity or high Nesting Depth, entangled components, methods with multiple concerns, classes with multiple responsibilities… leads to code harder to debug and to test.

Static Analysis Tools

…to be efficient, a bug finder static analyzer needs to be feed with more information than just the code. Typically, this extra information can be found in contracts and unit-tests code.

And in proof of Bugs being a personal issue, here’s another post reflecting on the seven listed points, where the author gives his own version of the main anti-bug technics.