james mckay dot net

There are a lot of common practices among .NET developers that get touted as “best practices” although they are nothing of the sort. A lot of them seem to be leftovers from the days about ten years ago when there was a lot of hype about n-tier although the people promoting n-tier didn’t properly understand the problems that n-tier was supposedly trying to solve. I’ve mentioned the repository-as-a-pointless-abstraction antipattern before, for example. Another related antipattern is too many projects in a single solution.

In general, you should always aim to keep the number of projects in your solution to an absolute minimum. For a simple web application, your solution requires exactly two projects: the application itself and your unit tests. For an application with a web front end and a console application, your solution requires four projects: the shared components, the web front end, the console application, and your unit tests. Products that deploy different applications to different servers may need one or two more for shared components, for instance, but the number should still be kept as small as possible.

Your solution does not — I repeat, does not — require separate projects for your controllers, your model, your business services, your repository, your shared components, your interfaces, and your wrappers round third party web services.

Your solution does not require multiple unit test projects. Some people create a separate unit test project for every main project in their solution. This is completely unnecessary: why not have a single unit test project for all of them? Of course, it may be worth having one project for fast unit tests, and another one for slower tests that need to run against a database, but over and above that, reasons for creating extra test projects are few and far between.

Your solution does not require multiple front end applications of the same type for deployment on the same server. You may need a back-end admin application on one server and a front-end public facing website on another, but you don’t need two back-end admin web applications for the same solution.

There are three reasons why too many assemblies are harmful:

1. Too many assemblies slow down compilation. When you have to compile a single project that references thirty external dependencies, the C# compiler only has to pull in these referenced assemblies once. When you have to compile thirty projects that reference thirty external dependencies each, the C# compiler has to pull in all thirty dependencies every time — a grand total of nine hundred referenced assemblies. This adds a lot of time onto your edit-compile-test-loop, which in turn knocks you right out of the zone and makes the whole development process feel like wading through treacle.

2. Too many assemblies make dependency management a pain. If you have to add a third party reference to thirty different projects, it is a massive, painful violation of DRY. If you have to swap out one reference for another, it is painful. If you have to add a third party reference to only a subset of those thirty, it is even more painful because you have to work out which assemblies require it and which don’t. And don’t even get me started on the problems you might face if you end up with two different projects referencing the same assembly from two different places within the bowels of your third party dependencies directory.

3. Too many front-end projects in particular make configuration and release management a pain. If you have two web front end projects for deployment on the same server, you have to configure them both together and deploy them both together. The more configuration you have to manage, the greater your risk of making a mistake. When you add a new configuration option, you have to update several different applications, and you increase the risk that you might miss one. If you have to change Copy Local from False to True for some assembly or other, you have to go through all your front end applications to make sure this is done correctly. Again, it’s a violation of DRY.

The main reason why people advocate a lot of projects in their solution is to attempt to keep the different logical parts of their code separate, so, for instance, they aren’t referencing System.Web from within the data access layer, or the data access layer directly from the UI, and they aren’t introducing circular dependencies. In practice, it simply isn’t worth it. If dependencies between your classes and namespaces really bothers you, a far simpler alternative is to buy a licence for NDepend instead. Certainly, you should have a very, very good reason to add a new project to your solution, and you should look to see what you can consolidate wherever you can.

Comments closed »

Posted at 08:00 on 20 June 2011.
Tagged: .net, antipatterns

David Richards of WANdisco has this to say about Git:

Funny, I was talking about this only today with an industry analyst and he has the same conclusion that we have. Git has its uses but probably not in the enterprise. OK please listen, I know that statement will upset a bunch of senior developers who think that GIT solves everything but it really doesn’t.

If you think about it GIT actually promotes anti-social software development; development in small, disconnected silos is not how software is developed in the real world. Most software is developed by teams whose members have a variety of skills who need to see what each other is doing and that’s the fundamental reason why GIT is not a threat to Subversion in the enterprise. It’s fine for the development of the Linux kernel but that model doesn’t work for most companies.

I’m sorry, David, but that is just wrong. It’s not just wrong in an existential sense, this isn’t just a Kantian viewpoint where you really need to consider what Schiller had to say on the subject, it’s wrong in the sense that 1+1=3 is wrong, or that the earth is flat is wrong, or that astrology is wrong. In other words, it’s just plain wrong. It is complete and utter FUD, it is a total misunderstanding of what easy, fluent branching and merging actually gives you, and it is totally detached from reality.

This argument, like every other anti-DVCS argument that you hear from Blub programmers and people who are being paid money to promote the likes of Subversion and TFS, boils down to, “These are the problems that you might encounter with DVCS if you don’t use it properly.” Compare that to the point that we DVCS guys make about centralised tools: “These are the problems that you are encountering because you can’t use it properly.” That is why Git and Mercurial are so popular these days among developers. They aren’t just a passing fad — the traditional, line-based, centralised model simply doesn’t work.

Oh, and by the way, there are plenty of success stories of DVCS in the enterprise.

The fear that’s being promoted here is that people will use branches as an alternative to communication. In practice, that simply doesn’t happen with Git and Mercurial users. While there’s always a possibility that you’ll end up with wildly divergent branches that give you a Big Scary Merge, this is a problem that can easily be avoided and is in fact generally self-correcting in the long run. Once you’ve got a feel for the limitations to what you can achieve with branching and merging, you tend to work within, and adapt to, those limitations. It’s called “learning from your mistakes,” which is an essential part of agile software development (and if you’re not doing some flavour of agile, you’re doing it wrong).

On the other hand, centralised source control, with its restrictive line-based model, presents you with problems that are difficult if not impossible to fix. It forces you to make compromises in how often you check in code for starters. Siloed, anti-social development happens just as much in Subversion as it does in Git, and with far worse consequences, since the equivalent in Subversion is delaying checking in anything at all till your whole work item is complete. When this happens, you run the risk of losing hours if not days of work — you end up with so many conflicts when you run svn update that you get confused and have to start over from scratch.

Before you start making a judgment about distributed source control, please do us all a favour. First, actually take the time to learn what you’re talking about. If you can’t explain to me what git bisect does, or what the tangled working copy problem is and why it’s a problem, or what a DAG is, or what the difference is between merge and rebase, then you’re not qualified to dismiss DVCS as unsuitable. It’s as simple as that. Then, actually try it out in practice on a non-trivial team project. Because again, if you are just going off hearsay rather than experience, you are simply not qualified to dismiss it as unsuitable.

Comments closed (1) »

Posted at 08:00 on 15 June 2011.
Tagged: source control

It seems that Microsoft has announced that HTML 5 and JavaScript, rather than Silverlight, will be the basis for front-end applications in Windows 8. The Silverlight community is up in arms.

This decision is hardly surprising. Silverlight was pretty much doomed from the start. It was a rival to a well-established, if flaky, technology — Flash — and pretty late to the party, so to developers not wedded to the Microsoft ecosystem (and that means 90% of web developers and designers), it was a great big yawn. And its prospects were effectively killed off when Apple decided to ban non-approved programming languages and frameworks from the App Store — therefore, no Flash, and by extension, no Silverlight. The iPhone and iPad are a huge market — if something doesn’t run on them, it isn’t cross-platform.

In the meantime, HTML 5 has come to the fore as a standard that looks set to render both these technologies obsolete. It is (partially at least, and increasingly) supported natively by web browsers without requiring any additional extensions. It’s an open W3C standard with a history spanning two decades, so it’s here to stay, as well as being a skill that can easily be transferred to other environments. XAML may be nice, but it has little or no traction outside of .NET.

For what it’s worth, this illustrates the risk of limiting your experience and skills to the Microsoft ecosystem. A lot of people have invested a lot of time and effort in becoming Silverlight specialists, and now they’re scared because it looks like those skills are set to become pretty much worthless over the next few years. I wouldn’t advocate ditching Microsoft altogether, but it’s always a good idea to be attentive to what’s going on elsewhere and not put all your eggs in one basket. Besides, if you’re familiar with what’s going on elsewhere, it can help to give you a better feel for which of Microsoft’s frameworks and technologies are likely to be a good long-term investment and which aren’t.

Comments (35) »

Posted at 10:00 on 3 June 2011.
Tagged: .net, javascript