There are a number of needed infrastructure pieces in order to effectively work with a team of developers and stakeholders. If you’re using a technique like lean and want to provide CI (continuous integration) along with a Kanban board then you can use web sites that provide this infrastructure.

Scott Hanselman  gave a talk at an OreDev in November 2009 titled, “Information Overload and Managing the Flow” that discusses some web sites for all the information that you receive on a daily basis. While his talk was specific to managing information the point is that there are free web sites for doing this.

Free is good but for a team it is no longer free. The free part is more geared for a single person working on a single project. This is ideal for trying out the web site and actually doing a small project.

What types of web sites would I use? For a team you need a few different web sites because I haven’t been able to locate an all-in-one web site that provides everything. If the team is going to be using a short iteration cycle approach and having the work exposed to the stakeholders you need to have four main areas covered.

You need some where to manage the short iteration cycles of the project. There are several ways to do this and for this discussion I will be using the Kanban approach. A web site I like is Agile Zen. The plan that fits best happens to be the most popular. This is the PRO plan at $29/month. It allows 10 projects, 10 collaborators, 10GB of file storage with email and IM notification and SSL encryption. This works good with a 3 person team and a few stakeholders.

The next area is you need somewhere to put the source code. The web site I like is Unfuddle. The thing I like about this web site is you can use either SVN or Git. The plan that I like is the Compact plan because it is the first plan to allow SSL. You really don’t want to be sending your code unencrypted. The plan provides 2GB of storage and 10 active projects for 20 people. In addition you get a dashboard, milestones and bug tracking.

So with source control and project management in place you now need a place to host the work. I currently use a hosting site for this blog but I don’t like the idea of using it to host the project. The reason is I want complete control of the project and many hosting web site charge more money for complete control. You can’t blame them because if you have control then you need to be hosted on dedicated server and not sharing a server. So I looked into cloud hosting. I haven’t made up my mind on what I want here. I’m mulling over two directions to take.

The first is using something like Amazon’s EC2. This service provides a resizable computing capacity in the cloud. Basically Amazon provides you with a server in the cloud.

The second option I’m considering is to use a VMWare hosting site. What this allows is a server that will have a VMWare image that can be used to deploy new web servers by deploying a new VMWare image. I like this and it may be the way I’ll go.

The important thing about a hosting site is that I have access to a database, preferably MS SQL Server. So no matter what way I decide I’ll need a db.

The last thing to consider is continuous integration. There are a couple of CI applications that I like, Hudson and TeamCity. Hudson it a java based application that runs in Tomcat and is built with a plug-in architecture. TeamCity is a CI and build management system offered by JetBrains (maker of ReSharper). What I really want is to get it free and put it on the hosting site.

That basically covers what I need have in place for a team developed project. There are other web sites to handle some of the things covered by Scott Hanselman and they may be needed too. These four areas address the infrastructure needs I have for team development.

This site is a screencast site that actually contains valuable information. I’m not saying that screencasts like Summer of NHibernate don’t have value. Summer of NHibernate is an excellent source for information for a good introduction to NHibernate.

What I like about TekPub is that use of domain experts on the subject. For Mastering NHibernate Rob Conery enlists the help of Oren Eini to dive much deeper into the material.

As the owners of the site put it, "Techbooks pretty much suck most of the time and you end up spending a whole mess of money when really what you want is to spend less time (and money) and learn from the people you trust."

If you’re looking for some excellent material then I urge you to check out TekPub.

I thought I would literally take a snapshot of my bookshelves. These first two are within two feet of my left hand. I would consider these the ones I look at the most.

These next two shelves are the ones that I used maybe 5 - 10 years ago but there still located in my home office.

This last one is in the ‘little house’ or mother-in-law house. These are at least 10+ years ago.

There was a thread on Alt.Net the other day about the importance of knowing the fundamentals. This got me to thinking about my own fundamentals. The Agile Software Development Principles, Patterns and Practices book has a section on Agile design. Casey Charlton has a blog about ‘What Determines High Quality Code?’. In both of these there is mention of the Single Responsibility Principle, SRP.

I’ve come across references to this principle before. What this boils down to is that any object should have only one responsibility. If you violate this principle and have more than one responsibility then this causes coupling. If change is necessary this coupling makes it difficult to make the change without causing side effects. Side effects make object rigid and this can cause unexpected results.

If you don’t have SRP in your object then changes may require rebuilding, retesting and redeployment in areas of the application that would not have to change except for the coupling.

This is one of the fundamental principles that any good developer should understand and sometimes one of the hardest principles to get right. Robert Martin in his book does note a corollary, “An axis of change is an axis of change only if the changes actually occur”. Let it be understood that in some situations it may be acceptable to have a coupling of responsibilities if the object will not be changed.

I’m starting a new project and I am refining my approach to solution development. The tools I mainly use are: VS 2005, NAnt, NUnit, Rhino Mocks and ReSharper 3.0. My design methodology is domain driven implemented by Test Driven Development. I’m not an Agile developer but I am TDD developer.

The first thing I do is create a blank solution. The first two projects I create are the Domain and Domain.Test projects. I always blow away the Class1.cs that VS 2005 creates from me.

The next thing I do is add this to a SVN repository. There isn’t anything really to save but I do have a solution with two projects. I do this so I can create the svn:externals SVN property so I can get my 3rd party DLLs. I’ve blogged about this before. I can now wire up the NUnit and RhinoMocks DLLs.

Now I’ve got the skeleton in place to begin development. The first thing is to start fleshing out my domain objects by creating a NUnit testing class. I have a ReSharper template that I use:

/*
* Created by: DuvallBuck
* Created: $DATE$
*/
using NUnit.Framework;
using Rhino.Mocks;

namespace $NAMESPACE$ {
[TestFixture]
public class $CLASS$ {
private MockRepository mock;

[SetUp]

public void SetUp() {
mock = new MockRepository();
}
[Test]
public void Test() {}

[TearDown]
public void TearDown() {
mock.VerifyAll();
}
}
}

The only thing I need to do is ‘Add references’ to NUnit and Rhino Mocks and I can begin with the domain objects.

The last piece is to create and NAnt build script. I have a template that I use for that too. I may blog about that in the future.

The last three months have been working in crunch mode. November was mainly spent working on core components. Getting NHibernate into the core and having two features using it. NHibernate wasn’t the only data access capability because there still is a need for ADO. I personally prefer not having to write SQL statements but then I have to write O/R mapping files. I do like code like this:

Repository<MyObject>.Save(myObjectInstance)

more than code like this:

ADOGateway.ExecuteNonQuery(”UPDATE myTable SET myColumn = 1 WHERE myPrimaryKey = 2″)

What got done was the data access layer that allows developers to pick NHibernate or ADO.

The core utility class does encryption/decryption of passwords so they are never in plain text. There are two flavors: one uses RC4 and the other a shifting, bitwise Anding of plain text password and random generated numbers.

Telerik grids at manage the most common core domain object without having to do more then bind the grid data source to an ICollection of core domain objects. Through composition of columns you get icons, links and check boxes without writing a line of code.

What got done was a lot of core components.

In December an attempt was made to convert a main feature in the asp/javascript over to the .NET world using the core components. This got a long ways towards completion but it was taking too much time and was too risky to replace a main feature. So this didn’t get done.

In January I focused on the new feature written in .NET that uses the core components. I modified the Telerik grid to only use the check box column and provide a new core UI component that is easily adapted to any domain object that uses an int identifier. I finished up the feature (actually a couple of minor pieces are still being worked on) and delivered it for beta.

In February what will get done is the testing of the new feature. The planning of the next version of core components.

While I’m not working from home I do interact with other company members via remote enabling applications like Skype and GoToMeeting. I have to interact with developers in four different locations and the developers in the office. There are about 100 employees literally scattered around the planet. HR/Payroll is in an east coast location. Support is mainly in the southeast but also in Europe. Development is located along the west coast from California to Washington. Each group is responsible for defined areas of the product.

The coding is all Windows but across asp/javascript, C and .NET C# mixing the old with the new. We run .NET code inside of frames. Some teams focus on the old and some teams focus on the new. We all code from the UI to the database. There are differences in architectural approach as well as implementation.

The latest release will be the first release that is bringing together the old and the new into the core product. The first company attempt at the new, .NET, was an add-on project that was not part of the core application. Now the new is going to be part of the old, asp/javascript.

Parts of the add-on code was refactored into the collection of core components that aren’t really a framework but cut across multiple projects. These include the initialization requirements of wiring the components with the features. A common data access layer that uses NHibernate. A core domain that is the objects that are relevant to all features. A utility class that handles encryption, connection strings and translation.

No one team is the sole owner of the core components. So much of the collaboration is done virtually. I’ve been at companies with multiple buildings and sometimes you would have to leave your building and meet in another. This is the first one that the teams, meetings and communication are relying some much on the power of the internet. This has been working and it is great to see that it can be done.

It sometimes is terrible in the software industry when you’re on a death march to beta. It has been very intense the last couple of months. The demo’s are not working. The code is not ready but the expectations continue to grow.

My deliverables are about 95% complete but I still have the testing and tweaking to complete. So it is much better now and I will do some blogging.

I use Telerik Web Controls in the work I do and these controls are used in multiple projects. I also use SVN as the source control system. Together I manage a single copy of the Telerik controls for multiple projects.

My SVN Telerik directories are setup like this:

I have a top-most Telerik directory that is a parent to the binn directory and the RadControls directory. In the binn directory I place the Telerik Web Control DLLs that are used in the projects. In the RadControls directory I put the different controls’ supporting files. This is the why Telerik has them organized so I just follow Telerik’s lead.

I usually organize my solutions like this:

MyProject
MyProject.Whatever
MyProject.Whatever.Test
MyProject.Whatever.Website
App_Code
App_Theme
bin
MyPages
RadControls
web.config
MyProject.sln

At the MyProject.Whatever.Website I set my svn:externals like this:

RadControls\Grid -r254 http://<SVN machine>/Repository/Telerik/RadControls/Grid
RadControls\Menu -r258 http://<SVN machine>/Repository/Teleric/RadControls/Menu
RadControls\Tabstrip -r804 http://<SVN machine>/Repository/Telerik/RadControls/Tabstrip
RadControls\Window -r268 http://<SVN machine>/Repository//Teleric/RadControls/Window

bin -r908 http://<SVN machine>/Repository/Telerik/binn

This brings all of the files I need to use the Telerik Web Controls in my projects and keeps around one single copy of the files. On top of that I’m not cluttering up the SVN with multiple copies of the same 3rd party files.

I haven’t had much time to do anything but code with a distinct lack of progress. Throughout much of October I was working on a task to add a new piece of functionality using the future framework of our product. This turned out to be an effort of futility. It wasn’t because the approach was wrong. The problem was the framework was too immature and I was constantly finding issues and having to wait for fixes from an already overworked group of programmers.

It was also at this time that I, by default, became the person that moved all of our code base from SourceOffSite to Subversion. This was no easy task because there had been a lot of inertia due to the fact that many of the longtime developers (read original developers of the code) were use to SOS. They knew that we needed to move but they weren’t looking forward to doing it. When we did move I couldn’t get them to use SVN best practices and so it was just a brute force move from SOS to SVN. About all I did get is for them to us a branches directory to develop against and not the original directory that I ported.

The first few weeks were phone calls about how to do this and how to do that. Once I was over that hump the only thing I’ve had to do is troubleshoot login issues that usually turn out to be case-sensitive issues that weren’t relevant with SOS. The only real problem was my inability to figure out how to move the history out of SOS and into SVN. This really hasn’t been a big issue but there have been times when even I wondered why I checked in a piece of code and didn’t have the history to jog my memory. But I did get a warm glow when one of the originals said to me that he really is liking SVN. Of course I knew that about SVN over the limited SOS but he didn’t and it was just nice to hear him say it.

The next big hurtle that has been devouring enormous amounts of my coding time is the fact that with the framework not being ready and the question became what do we do for the next release.

Again there is the problem of inertia and the introduction of new concepts to the original coders. The first most troubling decision is what to use for database access. We have a legacy database that is just a huge lot of tables that don’t have true primary keys or even any referential integrity. The primary keys are varchar (100) and orphaned records abound. The database was evolved over time without the benefit of database administrators or architects so it is really problematic. However it is easy to rebuild via SQL scripts and if something goes wrong you can ‘fix’ it by running the scripts. But this leads to a lot of SQL in javascript on ASP pages and is hard to manage let alone maintain. I’ve been known to unknowingly break the application by modifying the javascript or SQL scripts.

There is a small group of developers that have a grasp of best practices and experience in design patterns and this has made it possible for the introduction of different approaches to fulfilling our tasks. One group introduced an add-on feature that used NHibernate as the data access layer. This was very difficult and extremely tricky due to the lack of primary keys and missing records without referential integrity. Lazy-loading was impossible and because of this the general impression became that NHibernate sucked and why didn’t we just use ADO and splash raw SQL throughout our code behind of the ASPX pages. I’m not going to go into the reasons why we really need a good OR/M architecture except to say that as we evolve the database it will be much easier to change the .hbm.xml files then search through ASPX.CS files looking for SQL that needs to be modified.

This really came to the front when the decision was finally made that we need a true integer based primary key and not a varchar. It took many developers almost two weeks to fix all of the SQL statement to use the new primary keys. The one feature that was written using NHibernate took a few hours. The older was very fragile and it took many more weeks to find all the places that were broken while the NHibernate stuff just worked after it was modified. The NHibernate mapping was to just take the ID and make it the new integer primary key and move the old varchar ID and make it a property.

So we had another small group of developers who had a task that needed to be delivered and they hadn’t made a decision on what to do about the database layer. I had written a small mockup project that I used to play with NHibernate. I had some java background so I was familiar with the concept of OR/M. I told him to download my mockup and to watch Orin Eini’s one hour presentation on NHibernate. In about four hours with the help of Orin’s examples and the mockup he had his tables mapped and working with NHibernate. So that was the second feature that was using NHibernate. Of course the original coders eventually found out and with cover provided by my direct report NHibernate is now the data access layer of choice.

This brought about more angst because now that we are using NHibernate we needed a core architecture that can be easily and more importantly rapidly developed. So again I found myself with much to do and little time to get it done. So much of November was involved with getting this foundation in place. The goal for our small group was to create a component architecture that could be extended and used by everyone. The framework is still on the horizon but the delivery date for it is still not known. So it is no small task to provide this component model for the near term.

So the two teams already using NHibernate and myself have been working on what this architecture should look like and how it should be organized. We have buy in from the original developers so we have gotten the opportunity to introduce a lot of new ideas besides NHibernate. We’re starting out small with a domain driven design and a separation of the layers. The UI won’t have much in it but UI stuff. The middle layer will mainly deal with business domain and logic and the lower layer will use NHibernate to access the database. Small steps with the goal to deliver product. A lot is riding on this with no margin of error so I’ve been living on the edge and not able to blog much.

At least that is my excuse and I’m sticking with it. I hope to go into more detail of the approach being used. This will be to help me get it down in writing but more to the point it will help me clarify much of my thoughts.