Software Development Essential Practices

I was in an interesting discussion last night: what software development practices do you consider essential? 

While opinions varied, I think there was some consensus on a few items.  In my list I also include some tools.  Some of these were mentioned by the group, but consider them my own additions.  Also, I am making this list specific to .NET, but the list applies to just about every language.

Universally agreed Practices

• Source Control (1)
• Subversion
• VSTS ($)
• Vault ($)
• Local Development -- Every developer should have everything on their computer to run the system.  This includes all of the software and all of the source code.
• Bug Tracking - nuf said.  There are to many tools available to list here.
• TDD - Test Driven Development.  There was a little bit of back and forth, but the general consensus was that this should be done.
• NUnit
• MBUnit
• Rhino Mocks (2)
• TypeMock ($) (2)
• NMock (2)
• ORM - Object-Relational Mapping
• NHibernate 
• SubSonic - My person favorite
• LINQ to SQL - not yet, but I feel this should be on the list.
• LLBLGen ($) - Not free, but I've heard many good things about it.
• More
• Continuous Integration - Simple process that sits on a server and waits for things to get checked into your source control system.  When it sees something new, it gets all of the latest source code, compiles it, and runs all of the unit tests.  If there are any problems anywhere in that process it alerts the users (email, desktop icon, wave red flag, etc). (3)
• CI Factory
• CruiseControl.Net
• One Step Build - it is unbelievably cool to be able to click one button and have your entire project compile, run all tests, and possibly create an install in one step.  Personally, I do like it, but with the current set of tools this is one of the hardest parts to setup.
• MSBuild
• Nant
• BooBS/Bake (Ayende please, please, please change the name to Bake.  As cool as a project named BooBs could be -- I don't want to start an HR nightmare)
• FinalBuilder ($)
• Visual Build Pro ($)

Highly thought of but non-essential practices

• IOC - Inversion of Control - Everyone seemed to agree it was a good idea...but not actually essential.
• Castle Windsor - DotNetSlackers has a nice series on using this.
• Spring.Net
• StructureMap
• ReSharper ($) - Not a best practice per say, but it sure does make life easier. (4)

I'm sure I have missed some tools in the list, but it is the practices that are more important anyway.  But if you put a comment about any tool that I missed I will add it to the list.

(1) Source Safe was notably not in the list.  While I don't like it either, it is better than nothing.  But if your team is greater than 5 people or you have multiple people working on the same project you really should look at one of the other products on the list.

(2) Not a unit testing library, but a Mock Object library.  Pick a unit testing libarary (NUnit, MBUnit, XUnit), then pick a mock object library (Rhino Mocks, TypeMock, NMock) to use with it.

(3) I really need to talk about continuous integration more.  But it is one of those things that leads you down a path.  First you add source control, then you start adhering to separation of concerns, then you start unit testing and mocking more, then you add continuous integration, and then one step builds are all part of the mix.  One best practice leads to another, but they don't make a bit of sense without some of the prior pieces.

(4) If you are a Code Rush person instead of a ReSharper person -- carry on, you are in good company.

($) The cost money - not just beer, but may have free version versions as well.

Where are the DSLs?

DSL is a Domain Specific Language. It took me a couple of years to really wrap my head around what the term means. Now I have a bad understanding -- but where are the languages?

First off, in my understanding of a DSL, it might not be a proper definition. Frankly, I don't care if the language is a full on language, with it's own syntax and control structures, or just a set of very specific libraries that add classes and methods for easily reading what is going on inside of an existing language -- like C# or VB.NET.

Personally, I like the second one. I would take the inspiration from SubSonic and NHiberate. Heck, throw in NUnit if you want. The nice thing about using these as your examples is that you know things are easily extendable.

There are a couple that I am thinking of right now. I've been playing around with MSBuild and NANT lately. Those two tools have convinced me that XML sucks as a language format. How do you define a loop in XML? You can't do it in any terse format I can tell you that. XML is for data, not logic. That is why JavaScript doesn't look like HTML.

So no, I dont buy XML as a language. Personally, I have a hard time seeing through all of the angle bracket -- really, I do. They just seem to create a lot of unnecessary noise to me. Readability stinks, which hurts the overall expressiveness of the language -- not to mention aesthetics -- and maintainability is also terrible. Not a whole lot of syntax highlighters for xml these days. Debuggability: None. (is debuggability a word?) Either it works or it doesn't. If it doesn't...may the force be with you.

Anyway, back to the build scripts example. Basically, even if you have sample build scripts to work off of, it will easily waist one day of a developer's life to get a build script off the ground. Just to get started. Then countless more hours keeping the stupid thing up to date.

Why don't we have a build script DSL? Some already do exist, Ruby Rake is one. I'm considering learning it. I would like a C# based one, but I'll take Ruby if I have to.

Another use that I have thought of often has to do with ETL. Now I find I'm not alone. Ayande has recently been bitten by the bug. Which is good. Because with his given track record he might just be able to do it. Would you rather deal with Integration Services GUI or a language specifically designed for that purpose.

Bear in mind, these examples break down at one crucial point: threading. Both of the examples mentioned, ETL and Build Scripts, can benefit heavily from working in parallel. And that is one area that our current languages don't help us with a whole lot yet. It is easy to tell Integration Services to load a bunch of tables at the same time in the GUI -- that is a lot more work in C#.

Now it can all be mocked with the Unit of Work pattern so everything can be batched together. That would hide the complexity from the user of the language at the very least. But that still leaves a lot of complexity behind the scenes.

Which leads me to one of the new great hopes coming from Microsoft sometime in the future: PLINQ. Aka: Parallel LINQ. LINQ is all about building a better FOR loop. But it is still iterating over a list one item at a time. PLINQ takes things that next crucial step: multi-threading the iteration. And all without changing the syntax of LINQ. Now that is flippen cool. Unfortunately, I have heard no release date for PLINQ, and it probably wont come out with .NET 3.5 at all.

Anyway, those are my thoughts. I could go on, but I need to get back to work.

NAnt-NUnit error

Ever have a weird error and there is nothing on Google to help you? This was one of those problems.

We are using nant to run all of our builds, and using the NUnit2 for testing. Just to help out, nant has a task called nunit2.

Unfortunately, every time I ran our build I would recieve this error:

[loadtasks] Failure scanning "C:\Program Files\nant-0.85\nant-0.85\bin\NAnt.NUnit2Tasks.dll" for extensions. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

That could have been a bit more helpful.

Fortunatly Reflector was able to save the day. I was able to find the NAnt.NUnit2Tasks.dll on my file system (not to hard, the error message told me right where to find it), and loaded it into Reflector.

From there I checked the references of the dll. Two caught my eye. nunit.core and nunit.util. Still using resharper I tried to expand the references...Resharper could not find them. And they did not exist in the same directory as NAnt.NUnit2Tasks.dll. That meant that nant was looking for them in the GAC and they were not there!

A quick little script proved that to be true. It looked like this:
gacutil.exe /l nunit.util

I received this message:

The Global Assembly Cache contains the following assemblies:

Number of items = 0

OK, enough debugging, I ran the following two scripts to put those two dlls in the GAC and everything worked fine:

C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin>gacutil.exe /i "C:\Program Files\NUnit-Net-2.0 2.2.8\bin\nunit.core.dll"

C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin>gacutil.exe /i "C:\Program Files\NUnit-Net-2.0 2.2.8\bin\nunit.util.dll"

No thanks Google, I'll just fix it myself thank you very much.

Adventures in Agile Development

I've started a new project, with a new team, under a new development methodology. And for the most part I am happy with that. We have a small team of two developers and an architect/manager/used to be coder, and we are going as agile as possible.

Now Agile development means a lot of different things to a lot of different people. It is so bad that saying that you are an agile shop can mean almost anything you want it to. So to alleviate some of the confusion, here is some of what we are doing.

1. Daily Scrum. This is a 10-15 minute meeting every morning to talk about what is going on with your code. Where are we at, what are we trying to do.
2. Test Driven development. This means having tests for as much as possible (NUnit in our case). Granted, you cannot test everything, but there are development patterns that allow you to test most of what you do. Chief among them is the MVP pattern (Model-View-Presenter). I'll talk more about this later.
3. Frequent check-ins. It goes like this. Write a test for your code. Write the code. Make sure the test works. Check in. This means you are checking in up to four times per day. It also means you are less likely to get lost in all the things you are trying to do. And it means you need a source control system (we are using Subversion), and an automated build process (we are using NANT and Cruise Control).
4. The customer is allowed to get the daily build. This way they can keep up to date with what you are doing.
5. Now throw in an alphabet soup of other best-practice-somewhere technologies like Rhino Mocks, Spring, and NHibernate . You see there is a lot to learn.
   

Luckily, Agile and Test driven development have reached a critical mass such that there are now tools to help you with this process. I've already mentioned NUnit, NAnt, Subversion, and Cruise Control. But there is also the excellent Microsoft Team Systems that has all of those tools bundled together.

Another tool that wasn't listed that we are also using is ReSharper. Very cool tool with a lot of enhancements to Visual Studio.NET -- and a little bit of pain as well. ReSharper has an extremely large collection of shortcuts, so many that it actually overwrites a number of Visual Studio.NET shortcuts. But, it does have a feature to deal with that. Any time you his a shortcut that both ReSharper and Visual Studio.NET want, a dialog pops up asking which short-cut to use. I guess that is the best compromise. Anyway, for the side of ReSharper, the refactorings, and unit test integrations make it worth the cost of entry (a little over $100).

Now, this is enough for right now. I hate overly long rambling blog posts, and I'm afraid this will have to turn into a series. So, next time I'll write up what MVP, Spring, NUnit, and Rhino Mocks have to do with each other.