Excellent article on team development whose principles

Here an excellent article on team development whose principles have application within the realm of IT management. Read this in the MCPMag.com newsletter.


IMPROVING SOFTWARE DEVELOPMENT: Return of the Toolsmith Software developments teams of late are becoming so fractious, toolsmiths are becoming a necessity to help maintain focus and development best practices.
By Mike Gunderloy

Each team will need its own toolsmith, regardless of the excellence and reliability of any centrally provided service, for his job is to see to the tools needed or wanted by his surgeon, without regard to any other team's needs. The tool-builder will often construct specialized utilities, catalogued procedures, macro libraries.
-- Frederick P. Brooks, Jr., "The Mythical Man-Month"
http://tinyurl.com/a9u9b

Brooks was writing before many of my readers began their software development careers (indeed, I suspect before some of my readers were born). Despite that, the point about development teams (the "surgeon" in his example is a metaphor for the lead programmer) needing their own dedicated toolsmith has never seemed more true than it does today -- which just goes to show, I suppose, that things don't really change all that fast in our field.

THE JOY OF CONTINUOUS INTEGRATION
What got me thinking along these lines was some fun I had recently with revising my own working process on a couple of small projects. I decided that it was finally time to get end-to-end continuous integration running here, so I paused writing code long enough to set up a couple of servers (using virtual machines -- fortunately I had a relatively new dual Xeon server that wasn't yet heavily loaded) and started downloading software.

The first order of business was to get a Subversion source code control repository up and running. Then I installed TortoiseSVN http://tortoisesvn.tigris.org/ on my development box to give me an easy interface to give me an easy way to move code back and forth between the box and the repository. Next, I set up the other server as a continuous integration box with CruiseControl.NET http://tinyurl.com/3jepz as its backbone.

This server also got all the tools to manage the build: NAnt http://nant.sourceforge.net/ for scripting, NUnit http://www.nunit.org/ for testing, FxCop http://www.gotdotnet.com/team/fxcop/ for compliance checking, NCover http://www.ncover.org/ for code coverage checking, Simian http://www.redhillconsulting.com.au/products/simian/ for duplication checking, and Vil http://www.1bot.com/ for metrics generation.

With all the pieces in place, I was ready to dive into configuration. This mainly meant some time writing NAnt scripts, though there was also time spent figuring out why things that compiled on the dev box didn't compile on the build server ("oh, I forgot to install that library"). Finally, the job was done.

In case you've never used continuous integration, it's really pretty slick. Now, as soon as I check a change into the Subversion server, the CruiseControl.NET server starts beavering away. A few seconds later I get a little notification in the tray of my dev box, and I can go to a Web page on my intranet to see what all the tools have to say about the quality of my code (usually at least one of them has something uncomplimentary to say, but that's another story). It's a wonderful system; With a smoothly-running continuous integration server, you know that at any moment you've got code that's shippable (or you know exactly what's broken). If you're already using source code control, performing unit testing, and writing good specs, I recommend you look into adding continuous integration to your bag of tricks.

KEEPING THE ENGINE RUNNING
But there's a downside to all this plumbing, too. If your development process evolves to the point of depending on a continuous integration server and the software on it, you'd darned well better keep that server running. You'd also better keep the scripts that it depends on checked into your source code control. And don't forget that this stuff is cutting-edge: All the various tools are under active development, so you can expect to have new versions to evaluate and possibly install on a regular basis. I have the luxury that I'm just futzing around. You probably don't.

This is where I see the opening for the modern toolsmith.
Someone has to stay down in the boiler room, shoveling coal into the engines that keep the whole operation running.

Certainly, such positions have already existed in the software world for quite some time. If you go to Microsoft, for example, you'll find plenty of build engineers whose job is to make sure that Windows or Office comes rolling out of source code each and every day. But I think more and more smaller teams are going to realize that this has to be a dedicated position, rather than something that gets done by other developers as an extra job at the end of the day.

IT'S TIME FOR SPECIALIZATION
Let's think about the things that a dedicated toolsmith might do for a team of, say, eight or ten developers:
* Keep the build and source-code control and bug-tracking servers running
* Test new versions of tools the team is already using and install them as needed
* Evaluate new tools and suggest ones that can streamline processes
* Write scripts and tools specifically for the team
* Document processes and be ready to set up the software environment for new hires

I don't know about you, but I sure see a full-time job there.
Now, granted, these jobs already get done on small and medium teams. But how do they get done? In my experience it's by some combination of asking corporate IT to do things (at least, when there is a corporate IT to ask) and hoping they get done, stealing time from other projects, working late, and shoving things under the table to be done later (like that ever happens).
Wouldn't it be better to have one person who lived and breathed tools devoting full-time to making this stuff happen? Wouldn't it be better to have your other devs devoting their time to writing the product's code and not worrying about trying to be experts in NAnt and NCover and all the rest too? I'd bet the average eight-person team could pull one developer to dedicated toolsmith activities and not experience any loss in code productivity at all.

To my mind, this is just one facet of a change that's inevitably coming to software development as our tools and target environments get more complex: specialization. Many of us are generalists now, ready to dive in and learn whatever the project requires, whether that be a new communications subsystem, a build tool, a new UI design language, or whatever. But I think we're hitting the limits of generalists pretty quickly, if indeed we're not already there. Consider the demands that Windows Presentation Foundation will make on user interface designers -- do you really think every developer you know will be able to create an attractive user interface in the new world of Vista? I don't. We'll see user interface specialists commanding high wages from companies who have a clue.
But I digress.

MOVING FORWARD
It was Adam Smith, back in Victorian times, who pointed out the connection between specialization and economic growth. As large jobs are broken down into smaller components and workers become more specialized, they more expert in their jobs. This in turn means that they can do those jobs more efficiently, helping create more wealth. Though this principle hasn't been widely applied to software development yet, I can see no reason why it shouldn't be. Perhaps the toolsmiths of tomorrow will be the ones who lead us into a new era of creating richer software in a more efficient fashion.

More VB.Net samples then C#

Tom Archer has a post on how there are more VB.NET based code samples in MSDN now compared to C#.
I have a feeling of Deja vu.
When .NET was first released, almost all code samples that led to a great amount of misinformation being spread that C# was the language of .NET and that VB.NET would be dead in a few years time. There was also a lot of debate on how all VB developers should move to C# as they had no future.
Now when .NET goes into version 2.0, the adoption of VB.NET remains very strong, both in the corporate world as well as among hobbists. And atlast Microsoft seems to have realised that it may have been sending a worng signal, one it did not intend to.
Though I dont buy the explanation Archer gives, I still think it is good move to atleast debunk the VB is dead bogey.

Source: .net India

New .NET 2.0 Benchmarks

The results show that the .NET 2.0/Windows Server 2003 implementation of the benchmark application running against SQL Server 2005 outperforms the Java EJB-based WebSphere 6.0.2.3/RedHat Linux implementation by up to 183%. The results also show that .NET achieves significantly better price/performance ratios than WebSphere 6 on all implementations tested. This paper will also show that Java applications can get good performance when connecting to SQL Server 2005: the performance of the PlantsByWebSphere JDBC-based application that uses the soon-to-be-released Microsoft SQL Server 2005 JDBC driver is approximately equivalent to the performance of the equivalent application that connects to Oracle 10G.

Source:.net India and TheServerSide

The LINQ Project

The LINQ Project is a codename for a set of extensions to the .NET Framework that encompass language-integrated query, set, and transform operations. It extends C# and Visual Basic with native language syntax for queries and provides class libraries to take advantage of these capabilities.

Below are resources that you would like to use to jump into LINQ.

---

Featured Information
LINQ on Channel9Watch this Channel9 video with Anders Hejlsberg and Luca Bolognese as they explain what The LINQ Project is, and how it will help you create XML and data-driven applications.

LINQ Project Overview documentRead about the goals of, and the features proposed for The LINQ Project.

101 Samples using LINQSee The LINQ Project in action in these code samples. (Note: these samples are in C# only for now)

---

Information
Standard Query Operators
Standard Query Operators is an API that enables querying of any .NET array or collection.
DLinq Overview
Read about the features of LINQ as they apply to querying relational data.
XLinq Overview
Read about the features of LINQ as they apply to querying XML.

---

Downloads
C# LINQ Tech Preview Update for Visual Studio 2005 RTM Release
This is an updated version of the LINQ Technical Preview unveiled at PDC 2005. It includes samples, whitepapers, hands-on labs and compiler support to create LINQ-enabled applications using the RTM release of Visual Studio 2005 or Visual C# 2005 Express Edition.
Visual Basic LINQ Tech Preview
The LINQ Technical Preview includes samples, whitepapers, hands-on labs and compiler support to create LINQ-enabled applications using release candidate versions of Visual Studio 2005 or Visual Basic 2005 Express Edition. Note: this preview works only with the Visual Studio 2005 Release Candidate.
XLinq Hands-on Lab Exercises
Experiment with the proposed features of XLinq for querying XML files.

Videos
Future Directions for Data Programming in Visual Basic
Join Paul Vick and Amanda Silver as they discuss some of the features coming in Visual Basic 9.0.
Using Visual Basic as a Dynamic Programming Language
Paul Vick and Erik Meijer talk about the dynamic aspects of programming in Visual Basic, both in Visual Basic 2005 and Visual Basic 9.0.
C# 3.0 Language Enhancements in action
See the changes proposed to C# 3.0 in action. This video showcases implicit variable declaration, extension methods and lambda expressions. If you would like to follow along, you should install the LINQ Technology Preview first.
C# 3.0 LINQ in action
This video showcases the use of The LINQ Project with C# 3.0. In this video, LINQ is used to query in-memory data stores. If you would like to follow along, you should install the LINQ Technology Preview first.
C# 3.0 XLinq in action
This video showcases the use of The LINQ Project with C# 3.0. In this video, LINQ is used to query XML files. If you would like to follow along, you should install the LINQ Technology Preview first.
C# 3.0 DLinq in action
This video showcases the use of The LINQ Project with C# 3.0. In this video, LINQ is used to query relational databases. If you would like to follow along, you should install the LINQ Technology Preview first.

Hands-on Labs
LINQ Hands-on Labs
Use LINQ with in-memory collections, relational data and XML documents, and explore the query operators available in LINQ in these four hands-on labs.
DLinq Hands-on Labs
Create DLinq object models, use DLinq to modify data in relational databases, and explore the advanced features in DLinq in these hands-on labs.
XLinq Hands-on Labs
Query and manipulate XML files using XLinq in these hands-on labs.

/Gill
Resource: http://msdn.microsoft.com/netframework/future/linq/