Jeffrey Palermo (.com)

Sponsors

The Lounge

News

Advertisement

Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
How to produce a software product quickly, part 3 - level 300

In my first two installments of this series, I talked about:

These first two guidelines are very important.  The first drives efficiency, and the second drives effectiveness.  Even doing these first two well can leave a team spinning its wheels, however.  If parts 1 and 2 are fully implemented, we are now certain that the team is focusing on the small portion of work that delivers great value.  We are also sure that the team's time isn't being wasted with nonessential or repetitive tasks.  What's next?

Part 3: Use Powerful Tools

A skilled craftsman needs good tools.  First, the craftsman needs the correct tools.  Second, the craftsman needs those tools to be powerful.  A craftsman plowing along with inadequate tools is exerting more effort than necessary.  Why use a hammer and nail when a nail-gun is available?  Why use a screwdriver and wood screws instead of a power drill?

Workstation power

This is the most obvious, but sometimes neglected, tool for a software developer.  Does it make sense to have a highly-paid professional on staff using a mediocre workstation?  The programmer will spend time waiting on a machine.  The answer, of course, is no.  The newest member of my team came on board with a 3.4Ghz Pentium D (dual core) workstation.  1Ghz FSB, 10,000 RPM SATA drive, 2GB RAM.  He had never seen Visual Studio 2005 install in 10 minutes.  Compared to what I'm paying him, his workstation cost pennies.  He spends less time waiting on compiles.  The local build runs very fast as well.  In my mind, it is well worth the cost.

IDE & related tools

Many programmers with whom I talk use Visual Studio.  Just Visual Studio.  Some haven't been exposed to other tools for software development.  First and foremost, Visual Studio is a pretty good solution/project linking and compiling package.  It's pretty poor at helping the coding process, though.  There are a few neat extras you can unlock through SHIFT+ALT+F10 in 2005, but they are sparse.  Install Resharper into the IDE, and it comes alive.  It does use more RAM, but RAM is cheap, and the boost it provides is more than worth it.  Without Resharper, Visual Studio is just a glorified text editor that compiles.  With Resharper, you know about compile errors on the fly, and unused code is grayed out, so you know it's safe for deletion. 

Team tools

It's one thing to give an individual programmer the best tools money can buy.  It's another to focus on the team tools.  There are some tools that all members of the team depend on.  Besides the network connection and the printer, I'm talking about a revision control system and a build server.  It's important to have a quality revision control system.  The team needs to be able to rely on the branching and merging capabilities as well as the commit transactions.  My team uses Subversion.  It has proven itself time and time again. 

The build server is another shared asset.  It must be fast as well since every member of the team will have to wait on it at some point.  The build server can either have the build script run on it manually, or a CI server can run the build when new code is checked in.  Either way, the build needs to run fast, be configurable, and be reliable.  My team uses CruiseControl.Net with NAnt and MSBuild.

Other general, programming and debugging tools

There are many tools that help with a single part of development.  The IDE is the tool that stays open all day long, but other tools are just as critical for specialized tasks.  There is no way I can list them all, but I'll give a run-down of the tools I use:

  • Resharper - productivity add-in for Visual Studio (refactoring, code generation, etc).
  • Lutz Roeder's Reflector - disassemble the .Net Framework.  It's better than documentation.
  • CruiseControl.Net - build server for .Net
  • RealVNC - share the desktop.  Good for pair programming or informal presentations.
  • RssBandit - Keep up with the programming industry through RSS news, blogs, etc.
  • GAIM - Universal IM client.  Use to shoot over snippets of code, svn urls, etc to team members.  Supports all IM services.
  • Google Desktop - Launch programming tools quickly without using the start menu.  Find code files easily.
  • TestDriven.Net - run/debug unit tests right from the code window.  Integrates with NCover for code coverage metrics.
  • Windows Server Admin Pak - Remote desktop to many servers with the same MMC snap-in.
  • TortoiseSVN - Windows client for Subversion.
  • NAnt - build scripting.  In fact, you can script anything with XML using this.  We even use it for zipping up files.
  • NUnit - unit testing framework.
  • StructureMap - IoC container.  Uses attributes for linking interfaces with implementations.  Minimizes Xml configuration.
  • Who's Locking - find out what process has your precious assembly locked.
  • DebugView - hook into the debug stream locally or on a remote server.
  • DiskMon - monitor what's going on on the disk.
  • RegMon - see what keys are being read.
  • FileMon - see what files are being read.
  • Subversion - fast becoming the standard for source control.
  • Ethereal - monitor network traffic.  Find out exactly when and how often your application is communicating over the network.
  • VirtualPC or VMWare - test the software on all supported platforms.
  • Visual XPath - quickly create the correct xpath to get a node from an xml doc.
  • Regulator - Hash out regular expressions quickly with this tool by Roy Osherove.

The list is never ending

Always be on the lookout for tools that will save time or speed you up.  Tools are always improving.  It's important to talk with other professionals from different companies to see what tools are helping them.  Chances are that those tools can help you as well.


Posted Thu, Aug 31 2006 9:20 AM by Jeffrey Palermo
Filed under: , ,

[Advertisement]

Comments

Jason Haley wrote Interesting Finds: August 28, 2006
on Mon, Aug 28 2006 10:26 PM
Jason Haley wrote Interesting Finds: August 28, 2006
on Mon, Aug 28 2006 10:36 PM
Jiaozi wrote re: How to produce a software product quickly, part 3 - level 300
on Tue, Aug 29 2006 3:32 AM
Very good idea to list useful tools. Here are some more : Fiddler (http://www.fiddlertool.com) : Fiddler is a HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP Traffic, set breakpoints, ... Snippet Compiler (http://www.sliver.com/dotnet/SnippetCompiler/) : build and test quickly C# snippets ManagedSpy (http://msdn.microsoft.com/msdnmag/issues/06/04/ManagedSpy/) : Spy++ to .Net sauce
Jean-Pierre Riehl wrote re: How to produce a software product quickly, part 3 - level 300
on Tue, Aug 29 2006 6:18 AM
Hi, I read your blog for about a year. Every post is one of my thoughts about our job and Software Engineering in general. I agree your series of articles about productivity and how to develop software better and quicker. I read that kind of literrature since I was student but I am disappointed to see French people reticent to apply (even to test it) those guidelines or methodologies. I think it is a "state of mind" that differentiates Latin from Anglo-Saxon... I will persevere to convince my fellows and perhaps i'll start a blog about the French Touch (just my point of view, because frenchies are good, see http://www.dotnetguru.org for example)
Baldy wrote How to produce a software product quickly
on Wed, Sep 6 2006 5:53 AM

Jeffrey Palermo wrote an excellent three part piece on how to speed up development. Weel worth...

Baldy's view on the world wrote How to produce a software product quickly
on Wed, Sep 6 2006 5:54 AM

Jeffrey Palermo wrote an excellent three part piece on how to speed up development. Weel worth the read.

EZWeb guy: Jeffrey Palermo [C# MVP] wrote How to produce a software product quickly, part 4 - level 300
on Tue, Sep 26 2006 10:23 PM

In my first three installments of this series, I discussed: Eliminating waste Dodging as much work as

Luis Fraile wrote “If I can get away with NOT doing something, I will” o como no hacer trabajo de más
on Sun, Oct 15 2006 10:17 AM

Empiezo este primer artículo acerca de metodologías de trabajo para desarrollo, con una