Who uses this stuff?

I was ranting about my some of my favorite subjects to a colleague recently: Test Driven Development, Continuous Integration, Component Oriented Design, Transacted Source Control; and he asked, quite reasonably, if any of my clients had actually used any of these techniques. The sad answer is "very few", but it started me thinking. I've had 7 clients since I started doing .NET commercially in 2002, ranging from huge corporations to tiny four man web development shops. I thought it would be illustrative to summarize their use of tools and practices. So here we go.

When I first started this blog, my second post was a list of development essentials. For each organization I've listed the (very approximate, OK it's me guessing most of the time) budget and team size for the project and whether they used any of the essentials I mentioned in that post: Dedicated Build Server, Automated Deployment, Source Control, Test Driven Development, Tool Enforced Coding Standards and Bug Tracking Databases. Yeah, it's not the best list and it's mostly focused around my developer level outlook and things I've personally found useful. I'm also a bit of an agile fanboy and I could just as easily made a list of clients that follow agile practices, but that would have been a very short list of none. There are also plenty of analysis and project management tools and techniques, but that's for another time.

A large cable company (£100,000,000 - 100+ people)

Dedicated Build Server: yes

Automated Deployment: yes

Source Control: yes (source safe)

Test Driven Development: no

Tool Enforced Coding Standards: no

Bug Tracking Database: yes

This was a huge project. At the time they said it was the largest .NET development in the UK. We had a team from Microsoft on board and a lot of the development was off-shored. When I joined this project they had no centralized build or deployment process and it was in deep deep pain. It took a change in management and the lucky fact that they'd inadvertently employed a build expert or two without intending it, before a centralized build and deployment process was put in place. This allowed the project to hobble on for a while, but initial poor management and quality control meant that the code base was a monster and even surrounding it with the best processes and the cleverest people couldn't make it agile enough to be anything but a hindrance for the business. It's now being replaced with a third party product.

A tiny web development shop (£10,000 - 2 people)

Dedicated Build Server: yes

Automated Deployment: no

Source Control: yes (subversion)

Test Driven Development: yes

Tool Enforced Coding Standards: yes

Bug Tracking Database: no

These guys were on the ball. They were doing a lot of things right: centralized builds, decent source control (subversion) and actually doing TDD for once. The simple reason was that the lead technical guy was very good and really cared about following good practice.

One of Europe's largest software service companies (£1,000,000 - 10 people)

Dedicated Build Server: yes

Automated Deployment: yes

Source Control: yes (source safe)

Test Driven Development: yes

Tool Enforced Coding Standards: yes

Bug Tracking Database: yes

This was a large government contract. When I joined the project they were in a whole world of pain six months had passed with almost nothing of value being delivered. Maybe because of this they actually listened to my incoherent rantings and allowed me to re-architect the entire application as well as introduce TDD and have a big input on the build system.

One of the world's largest insurers (£100,000 - 4 people)

Dedicated Build Server: yes

Automated Deployment: yes

Source Control: yes (source safe)

Test Driven Development: yes

Tool Enforced Coding Standards: yes

Bug Tracking Database: yes

I was the single developer on this integration piece, so I used all my favorite tools and techniques. I was aided by having one of the best architects I've ever worked with on the team. Another very strong developer developed the build and deployment process. A very pleasant experience.

One of the UK's biggest banks (£1,000,000 - 10 people)

Dedicated Build Server: no

Automated Deployment: no

Source Control: yes (source safe)

Test Driven Development: no

Tool Enforced Coding Standards: no

Bug Tracking Database: yes

This was similar to the previous project, another integration piece, but almost at the opposite extreme in terms of their understanding of modern development practices. I left.

One of the UK's busiest web sites (?? - 1 person)

Dedicated Build Server: no

Automated Deployment: no

Source Control: yes (source safe)

Test Driven Development: no

Tool Enforced Coding Standards: no

Bug Tracking Database: no

These guys were pretty good in terms of software architecture, but had almost no process. It showed how far you can get with some clever people even if you're just hacking, but they were starting to feel some scale pain. They were working on implementing centralized build and deployment but hadn't considered TDD.

A small fast growing software company (£20,000 - 3 people)

Dedicated Build Server: no

Automated Deployment: no

Source Control: yes (source safe)

Test Driven Development: no

Tool Enforced Coding Standards: no

Bug Tracking Database: yes

These guys are very similar to the previous project. I have to watch what I say because I'm still working with them, but I think they'd agree that they're starting to feel a little scale pain and starting to talk about putting more process around what they do. On the positive side there are plenty of people there interested in writing good software and it will be interesting to see what practices they adopt as the company grows. I've ranted about TDD at one of our development meetings and got a mostly positive response.

 

OK, so what have I learnt from the last five years (I try not to think about my former life as a VB Mort :). Well, the same pattern seems to repeat itself. A successful small product, initially often written by one person will grow and attract more and more resources. As the project grows more people are hired and then it's a race between how quickly the team realizes they have to adopt larger scale techniques and how quickly the software decays. A lot depends on the quality of the initial product and how well the lead developer passes on his design vision and how consistent the code stays. But even with well architected code and good developers, once the team gets past a certain size, things like having centralized build and deployment become essential if there is to be any confidence that the software can be integrated and tested. Without continuous refactoring code decays and you can't refactor with confidence if you don't have unit tests. I think that TDD is the most important technique to emerge in enterprise software development, certainly in the ten years I've been working in the field. It provides a step change in any teams ability to build great software. It's still mostly unknown in the Microsoft development world, but I think it makes such a great improvement that it will inevitably see progressively wider adoption.

Of course the quality of the people on the team is the most important factor, but then good developers adopt good techniques so they tend to go together. I think it's important that everyone agrees about what needs to be done. It's always a terrible mistake to try and impose techniques from above. To a certain extent you can enforce centralized build and deployment, but insisting on TDD without proper buy-in is almost always counter-productive. Trying to enforce design practices is a waste of time; nobody can do good software design except good developers.

Of course you can make successful software without worrying about architecture, clean design or testing of any kind, so long as it has one essential property: it's small. By small I mean maybe something written by one person over a month or two. But as soon as the software grows over a certain scale, if you don't start to listen to the lessons of people who have built large scale software and suffered for it, you are going to feel pain.