Monday, January 25, 2010

Tools and Techniques I Recommend to Clients

I've been doing full time consulting work for about a year and a half now and for the most part I love it. I get to go into new organization with different needs and concerns, meet new people and try and improve their project, process or just in general help contribute to their business needs. Every client is different but there are some universal tools, practices or concepts that most anyone can benefit from. When given the opportunity to express these areas of improvement here are the things I generally talk about. It should be noted that the tools on this list are mostly geared toward .NET as that's what most of my clients use but some of the concepts are universal.

Tools

 


  1. JetBrains Resharper - This tool is first on my list because in terms of productivity gains from tooling Resharper may be the single best thing your money can buy. Microsoft has made some serious strides in bring refactoring and TDD support into visual studio but in my opinion they remain second class citizens especially when you compare the out of the box support with what Resharper gives you. To be honest Resharper could sell JUST search by class name (Ctrl+N) or Search by File Name (Ctrl+Shift+N) and i would buy it. The upcoming version is said to provide better support for ASP markup, HTML markup and Javascript and I'll be buying it on release day.

  2. Balsmiq Mockups - Among the private or small-cap development community the concept of using pen and paper or intentionally "messy" mockups has become a bit more prevalent. Unfortunately in "corporate america" my experiences have been that the business still expects a mockup to look like the final product. This results in somewhat rushed layouts becoming law and UX suffers. Balsamiq is a great mockup tool for communicating the general flow of an application without setting expectations to the point where they are no longer malleable.

  3. JetBrains TeamCity - I'm going to talk about Continuous Integration and having a build environment in a moment but in terms of tooling for the concept TeamCity is excellent. It's a fairly straight forward UI and eliminates a lot of the configuration "older" tools like ThoughtWorks CruiseControl .NET required.

  4. ThoughtWorks CruiseControl .NET - Ok so i just took a shot at CC.NET by saying it required a lot of configuration, and that's true, but it's also the most mature build system out there for .NET. In my opinion (and limited experience) Microsoft's build offering can't hold a candle to the community support and stability of CC.NET. I've seen it used in single team shops and giant enterprises. Oh and did I mention it's free?

  5. nAnt - This item may fall off the list soon in favor of Rake if Kevin's experiences stay consistent. nAnt is essentially the scripting language you will use if you use CruiseControl or TeamCity. You could use MSBuild and whatever platform MS set up for TFS but i find nAnt has better community support.

  6. NUnit and RhinoMocks - I'll write more about these when I talk about TDD, but in my experiences they remain the best (and most stable) tools for testing on .NET. MSpec is an up and comer that could shift my direction.

 

Processes


This section is going to sound like an Agile To Do list but that's mainly because a lot of the practices that people think of as "agile" are actually just a good idea regardless of your actual development methodology. Some of these seem like no-brainers but it's amazing how many organizations still lack some of the most basic and most established concepts in software development.


  1. Source Control - My first item is my most important. If you are doing file system source control, making copies of your application and praying to whoever you pray to that you don't lose something you are doing it wrong. There is no "but i don't like checking things out" or "but its so much work to maintain that repository" or even "but I'm the only programmer" your doing it wrong. You should not being writing a line of code without a repository set up and ready. You also have no excuse,there are cheap or free hosted options or you could always set up subversion, mercurial, git or even TFS and do it in house.

    • Distributed Source Control - I would recommend a system like Git or Mercurial for managing your source code over a system like TFS or Subversion (or god forbit SourceSafe.) All of those (except maybe SourceSafe) are great systems and offer a huge benifit especially if you aren't using source control yet, but today the latest and greatest (and for a reason) are the distributed source control systems. In short DVCS is better because it offers easier branching with less cost, less down time, your people can work away from the network and still have full history, commit and branching and if anyones repository gets messed up everyone on the team has a copy of it. There is a much smaller chance of failure.

    • Non Locking VCS - This is a HUGE pet peeve of mine and I still don't understand why some systems default to file locking (I'm looking at you SourceSafe and TFS.) When you lock files on checkout you ensure that no one else on the team can work on that file. That means if I need to make a change to fix a bug or add a feature I have to either email my change to a teammate and ask them to make it, mark the file as writable and change it anyway then hope i remember not to overwrite my changes when i eventually can check it in, or bug someone to check in their code in a potentially incomplete state so i can make my change. Its a huge pain in the ass and it slows me down. Also for every bug i need to fix i probably spend 80% of the time finding the bug and 20% fixing it. If i spend that 80% of the time, find out I cant change the code and move on to something else in the meantime guess what, I'm going to spend that 80% again finding it when the file is checked back in. HUGE productivity loss.


  2. Some sort of project management approach - Preferably a flavor of agile, but in this category even waterfall is better than the ad-hoc "hope the project is done on time" approach. It's kinda remarkable but I still run into clients that don't really do anything with regards to project management. Essentially a business analyst or business person goes to the development team and says "i need this built by this date" and people start typing. Scope and priority changes but in a "your half way through this and now you need to stop and work on this" manner and not in any sort of controlled way. Code is lost, productivity falls and in general it costs the organization way more than it should.

  3. Continuous Integration - CI, put simply, is the idea that you should have some automated way to compile your code, execute metrics and tests against it and provide feedback to the team if it is still in a good stable place. In some organizations all you have is the compile step, that's ok set up a CI server anyway. It's worth it. People have a tendency to check in bad code when no one is watching, if the build goes red they know someone is watching. On a related note my next CI server will be named B1g Br0th3r

  4. Test Driven Development - Books have been written about this topic but basically TDD is the notion that you should write a test for your code before you write your code, then write the code to make that test pass. It ensures that every line of code you write is adequately tested on a logical level (it doesn't get you out of manual system testing but it should cut the time and resources needed for that if done properly.)

  5. Automated UI Testing - This one is a bit controversial as of late but I'm still recommending automated UI testing if a client has a technical QA team member who can maintain the test. These type of tests essentially drive the UI of your application to attempt to determine if it is executing as expected. They ARE fragile (software changes will drive changes in these tests) but if done by your testing team they provide a good feedback loop between development and QA. They also hit a layer that TDD usually misses. I would NOT recommend paying for tools, if your doing web dev Selenium and Watin are great and free. Also for a group with no TDD experience sometimes this type of testing can be an easier addition to an existing codebase but please don't get comfortable, learn TDD.

 

The Rest


Some quick props and a disclaimer.

Redgate SQL Tools - Best SQL Server Toolkit for DB types.
Beyond Compare - A great file comparison tool for windows.
SnagIt - A great Screen Shot application for windows.
AgileZen - An excellent online Kanban board build by a NorthEast Ohio local. A lot of people love pen and paper for Kanban but if your working with a distributed team AgileZen is the best I have seen.
Basecamp - Another great project management tool by the inventors of Ruby on Rails.

Disclaimer: Redgate, Jetbrains,  Scooter Software, Techsmith and Balsamiq all provided swag for Technic picnic I held last summer. That said their products rock and that's why I contacted them asking for a handout in the first place.

2 comments:

  1. Originally from Kevin Berridge -

    Great sum up. I definitely need to take a closer look at many of the items on this list.

    ReplyDelete
  2. Originally from John Miller -

    Great list Josh! Wouldn't it be great if *all* (.Net) teams were already using most of these resources? :)

    Another useful tool to add to the list is LinqPad. Great for quickly testing C# code snippets.

    ReplyDelete