Now when somebody writes that on their blog, they’re generally criticised as being elitist and condescending. This is because they tend to talk about the “alpha geeks” or the “20%,” and everyone else or the “80%.”

I’m not going to say that. But I am still going to say that there are two types of programmer.

• Those for whom programming is a means to an end.
• Those for whom programming is an end in itself.

If you’ve been following me on Twitter, and if you’ve read my recent blog posts, you’ll know that this has been something of a theme for me for the past couple of months or so. What got me going about it was reading this remark in a blog post by Jeremy Miller a few months back:

I had a great time at CodeMash yet again. For those of us who look at software development as more of a lifestyle than just a way to meet the mortgage, these kinds of events are like a huge dose of nutrition for the soul. I really liked Scott Chacon’s keynote address and it’s got my head a going about how to make our workplace better (see this again).

It’s not a bad post, all in all, but whoa there. Since when was software development supposed to be a lifestyle?

Don’t get me wrong here. I’m all for being passionate about programming, for sharpening the saw, for improving your skillset, for using the best tools for the job, and all that, but when I hear of people describing software development as a lifestyle, I wonder just what makes them tick. And this isn’t a criticism of Jeremy either. It’s more a criticism of myself. There have been times when I myself have slipped into that way of thinking, and I’ve not found it to be beneficial. It’s easy to fall into that trap when you have the kind of mind that enjoys programming, and it takes a good deal of self-discipline to avoid it. In fact, paradoxically, I find that when I get into programming-as-an-end-in-itself mode, I end up getting less code written, not more.

This, in a nutshell, is what’s been behind a lot of the things I’ve been blogging about recently. It’s been behind my recent decision to stop using vim, for instance. For that, and everything else I’ve been looking into, I’ve been asking myself the question: is this a means to an end, or is it an end in itself?

So to those of you who would want to persuade me to reconsider learning vim properly, or to switch from Mercurial to git, please allow me to remind you of one important fact.

You can’t learn everything.

As programmers, we face a firehose of new tools, new technologies, and so on. Many of these are promoted loudly with great fanfare on the Internet by their fans. In the case of some (*cough* git *cough* ruby on rails *cough*) the fanboy hype is deafening. Most of them are claimed by their proponents to be counterexamples to Fred Brooks’ classic essay, No Silver Bullet. Almost none of them are anything of the sort. Yes, they are beneficial to a greater or lesser extent, but in most cases, there are trade-offs.

It simply isn’t possible to give all of them more than a cursory once-over. You have to triage what to learn and what not to learn. Aggressively. Learning vim would rob me of time familiarising myself with other, more important technologies such as Selenium or backbone.js, for instance. Frameworks and tools that you do learn are huge and complex these days, and if you try to learn too many of them, you end up with a very superficial understanding of them that can lead to problems. Either that, or else you end up spending so much time on the computer that you damage your health and your relationships with other people.

So in the past few weeks, I’ve been taking a good hard look at everything I’m doing, re-evaluating what I should be taking up, what I should be dropping, and what I should just allow to carry on as-is. With that in mind, I’ve been formulating some criteria by which I should decide what to adopt, and what to ignore. With everything I’ve been doing, I’m asking myself a few pertinent questions now:

• Does this solve a problem that I am currently facing or am likely to face in the not too distant future? If so, how effectively?
• Will knowing it enhance my career prospects? More importantly, will not knowing it harm my career prospects?
• Are there any examples of real-world applications using it, or is it all smoke and mirrors?
• What is the ramp-up time, and is it worth it?
• Is it in line with the direction I am heading, or is it a distraction?
• If it makes programming easier, does it do so at the expense of the end users?

The last point is a key implication of programming being a means to an end rather than an end in itself. If programming is a means to an end, and you care about your end users, you will base your choice of tools and frameworks on what serves them best. On the other hand, if programming is an end in itself, you will choose the cool languages and tools that everyone is raving about, but at the expense of your audience. This is of course what WordPress got right but Diaspora got wrong.

I’ve decided that in terms of tools and technologies, I should focus on my core competencies: namely, the Microsoft .NET stack, HTML 5 and JavaScript. I also want to up my game as far as test-driven development is concerned — hence, I’ll probably have another, closer look at MSpec — and also get to grips much more with agile development methodologies, in particular Scrum, which we have been using at work for the past year or so. As far as my other skills are concerned, such as PHP, Python, Django and Linux, these are useful skills to have, but how much time I spend on them from now on is something I am yet to decide. While it’s good to diversify to an extent, I don’t think much of the Pragmatic Programmers’ suggestion that you should learn another language every year, simply because that takes you into the realm of programming for programming’s sake, and besides, I don’t think it’s realistic, unless you are content to be a jack of all trades and master of none.

Bloggingggaaaaaaaa!

The ALT.NET movement makes me feel a little bit uneasy somehow. While there are some pretty good people in there, and I fully support the aim of finding better ways to do things, the movement as a whole seems to have largely degenerated into a clique of programming-as-an-end-in-itself Ruby fanboys with inflated egos who only do .NET under protest for their day jobs, and who complain about Microsoft tools purely for the sake of complaining about Microsoft tools. I ended up in conversation on Twitter with several of them in the wake of my TFS==Lotus Notes blog post, and I think some of that may have rubbed off onto me. Certainly, I’ve been doing far too much complaining recently, and I’m sure it doesn’t make me look good.

I’ve come to the conclusion that the programmers most worth following on Twitter, most worth subscribing to in Google Reader, are the people who are building end-user applications aimed at non-developers. This isn’t necessarily because they’re smarter — frameworks and developer tools are technically more challenging beasts to write and maintain — but because they tend to have a better grip on reality. Building end-user applications puts activities such as socialising and speaking to non-programmers right at the heart of programming: you have to talk to people before you start in order to get ideas, and then you have to talk to them afterwards in order to make sure you’ve delivered something that they can use without getting confused. And of course, you also have to talk to them in between times to make sure you are on the right lines. This is where agile software development hits the nail on the head — developers are expected to talk to the customers on a daily basis. On the other hand, only ever building programming tools and libraries, and little or nothing else, seems a bit self-serving to me.

At the same time, I’ve also been asking the same questions about my blog. Over the past few years, I’ve constantly found it to be a very time consuming animal, where I don’t see much benefit coming out of it, and I keep wondering why I do it. Most of my recent blog posts have said, “You should be doing this,” or “You shouldn’t be doing that,” or “This is a cool tool,” or “That process is bad,” or other things in that vein, and I’ve been saying very little about what I’ve actually been doing myself. This is just punditry, and I don’t want to be just another talking head. We have too many talking heads in our industry, and it gets rather boring after a while.

I also think I got carried away somewhat with the whole Mercurial/source control thing. Now don’t get me wrong: I still maintain that Mercurial is the best source control tool available today by a long shot, that only git comes anywhere near it, that the old-school centralised model is past its sell-by date and no longer fit for purpose, and that if you’re not using a DVCS, you’re harming your productivity, making a rod for your back, and exposing your project to unnecessary and unacceptable risks. But there comes a time when you have to let things drop, otherwise you end up coming across like a noisy fanboy yourself and you just annoy people who have missed them as they flew straight past coming out of the firehose. In fact, this fanboy attitude is totally out of order in the Mercurial culture itself, where viewing programming (and by extension, source control) as a means to an end and not an end in itself is very much the norm.

I’ve therefore decided that I need to take a break from blogging for the next few months. Quite when, or even whether, I return is anyone’s guess, but if I do, I’m not planning to carry on writing in the same vein as I’ve been doing so up to now. If I’m to carry on blogging, I want to build stuff that I can talk about and showcase here on my blog first. Unfortunately, at the moment, most of the code I write that’s worth talking about is at work, and there’s obviously a limit to how much I can write about that. But the Agile Manifesto tells us to favour working software over comprehensive documentation, and as a corollary, the contents of your github or bitbucket account say more about you as a developer than the contents of your blog.

I’ll no doubt continue working on some personal programming projects in my spare time. In fact, hopefully I’ll be able to spend more time working on programming projects without getting distracted by blogging about x, y or z. But it will have to be time-boxed anyway. During the week, I am out of the house from seven in the morning until seven in the evening, which doesn’t leave me much time for anything other than sleep, and I want to free up more time for socialising, church activities, and developing other interests that don’t involve sitting over a computer.

1. Pet projects don’t need to be extensive or advanced for you to stand out from the crowd. The vast majority of .NET developers have no personal projects whatsoever, so as little as one evening a month spent on them should be more than adequate.

2. Can we cut out all the cringeworthy Bravo Sierra about “passionate developers,” please? There are less clichéd ways of saying much the same thing, and besides, I get the impression that some recruiters view passion as a substitute for competence. It isn’t. You get plenty of passionate developers who think that Pokémon exception handling is perfectly acceptable, for instance.

3. It’s also possible to have too much passion for programming. People who get too passionate about programming forget that it is a means to an end, and not an end in itself. A telltale sign that you are dealing with such a person is that their github account contains nothing but vim scripts and clones of developer tools and class libraries. If, as a recruiter, you want to look for personal projects, look for ones aimed at non-developers. That way, you get some indication that you’re dealing with someone who at least has some grip on reality.

Take a look at its list of about eighty or so “interesting” repositories, for starters. There’s a lot of cool stuff there: Prototype, Scriptaculous, Ruby on Rails, MooTools, Groovy, Sinatra, Redis, Symfony, and so on. The list changes from time to time, and I have no idea what criteria are used to construct it, but at the time of writing, with only one exception  — phpBB — every single repository on the list is either a programming language, or a programming framework or library, or a programming tool.

You can see something similar — and quite surprising — when you look at the list of most popular languages on Github. The dominance of JavaScript, Ruby and Python is not all that surprising, but the fourth most popular language on Github is Shell. In other words, bash scripting — the Linux equivalent of DOS batch files or PowerShell.

C# — probably the most sought-after programming language by employers in the Real World — does not appear in the top ten. Clicking through to it from the right hand column shows that it is number twelve. But which is number eleven? After a minute or two of clicking on educated guesses then completely at random, I discovered, much to my surprise, that it is actually VimL.

I kid you not. Github apparently has more repositories dedicated to the scripting language for Vim — a console-based text editor mainly used by hard-core geeks — than to C#.

Why am I highlighting these things? Because they are indicative of a problem that seems to be plaguing the open source world and the programming blogosphere these days. There is far too much of a focus on processes and tools, and not enough of a focus on individuals and interactions. I’ve been getting too much inclined that way myself in the past couple of years here on my blog and on Twitter, and I’m getting weary of it.

You can understand why this would be. Programming languages, tools and frameworks are fun to work on because they’re hard and make you a better programmer, they scratch a personal itch, and they look good if you’re trying to attract the attention of trendy startups in Silicon Valley. And of course these things are important. But they are written by open source developers, for open source developers. They are of no direct interest whatsoever to non-developers.

Where are all the WordPress plugins and themes? The personal productivity software? Personal finance? Health and fitness? Photo and video editors? Education? Motoring? Foreign language learning? E-commerce? Geolocation? Astronomy? Twitter and Facebook clients? Games? Screensavers? Android and iPhone apps? Yes, they’re out there, but you have to hunt for them. And among all the blog posts about how CQRS, NoSQL and IOC containers are so cool, where are all the success stories telling us how they’re being used in the Real World?

Programming does not exist in a vacuum, folks. If we were serious about the Agile slogan, “Individuals and interactions over processes and tools,” projects aimed at non-developers would predominate. As it is, a lot of it seems like a case of programming for programming’s sake.

A lot of developers are introverts, and find it easier to spend time writing code than interacting with people. But if you want to produce something that’s really useful, you need to spend some time getting out from behind the computer, developing other hobbies and interests, and interacting with people. After all, that’s where the ideas for useful software come from in the first place.

Being a successful developer really does require you to put individuals and interactions over processes and tools.

Queuing at a station counter or a ticket machine is something I only normally have to do once a month or so but all the same, it’s still a complete faff at quarter past seven in the morning, especially if, like me, you’re not a morning person. Getting to the station that extra bit earlier and ending up in a queue of twenty other commuters at that time of the morning when your train is due in five minutes is just a little bit stressful.

On the other hand, I pay a regular visit to Tesco or Sainsbury’s at least once a week. When I do, I have much more leeway with my time. It’s later in the day so I’m not bleary eyed and newly out of bed. Having to stand in a queue for ten or fifteen minutes doesn’t faze me nearly so much. It would be a much more seamless fit into your average commuter’s weekly routine.

1. If DVCS had come first, would Continuous Integration ever have been invented?
2. What exactly do people understand Continuous Integration to be anyway?

In answer to the second question, you could of course point me to Martin Fowler’s excellent essay on the subject, but I just want to make sure that you’ve read and understood it yourself. For it contains one point that most people seem to overlook when discussing CI, and it is this:

Everyone integrates their work into the main line every day.

For Subversion, this would be trunk. For Git or Mercurial, it would be a single master repository that does not permit multiple heads.

Clearly, most teams do not do this. While there are many tasks that you can break down into functional tasks of less than a day, there are many more that you can’t. Consequently, if you wish to adopt this approach, you will be checking incomplete work potentially into production, hence the need for feature toggles.

It was this, specifically, that I described as a workaround for poor branching and merging support.

Here’s a little thought experiment. Martin Fowler wrote that article in 2006, at a time when few people had even heard of distributed source control. Just suppose that Git had come to prominence ten years earlier and that the DVCS workflows with frequent branching and merging were standard practice industry-wide. Would he have mandated pushing your changes to the mainline on a daily basis then?

Somehow, I don’t think so, and even if he had, it would have gained little or no attention. It would be widely regarded as a solution looking for a problem.

For what it’s worth, long lived branches are a bit of a straw man here. If you are following an agile methodology such as Scrum, your features will naturally be fairly limited in scope anyway so you shouldn’t ever reach that point. Nor am I convinced by the assertion that your mainline should act as a point of communication. That’s what your daily stand-up meetings, sprint retrospectives and face to face communication throughout the day are for.

Of course, there are some situations where a daily integration approach will be beneficial, or even necessary. If you are stuck with an old-school centralised source control system such as Subversion or TFS, for instance, you don’t have much choice. While it is possible in principle to adopt a branch per feature approach with these tools, in practice they enforce so much ceremony and risk around creating, merging, and switching between branches that it simply isn’t practical.

Another scenario is where your team is new to branching and merging. Some novice DVCS users start off with a lot of magical thinking and unrealistic expectations about branching, dive straight in at the deep end with long lived branches and indiscriminate refactoring, then wonder why things go pear shaped when they attempt to merge. My general recommendation is to start with a CI-style approach and gradually expand into small and then larger feature branches as your experience and maturity as a team grows.

Third, some tasks are better suited to feature branches than others. Generally, the more dependencies your code has, the more frequently you will need to integrate. Changes to your data layer or shared classes will need to be integrated pretty much as soon as they’re done, especially if you aren’t following the Open/Closed Principle, whereas on the other hand, changes that largely incorporate new functionality, or that only affect your UI layer, will work fine even on long lived feature branches. Knowing where the limitations and possibilities lie and how to mitigate them allows you to adopt a much more flexible approach to feature branches. But it is certainly possible to adapt your approach to the maturity and expertise of the team, and the needs of your project.

Finally, it is worth noting that feature branches are only incompatible with this one specific aspect of Continuous Integration. Other aspects of CI, and of course pretty much everything about Continuous Delivery, are completely orthogonal concerns, and there is absolutely no reason why you should not do both.

• ThoughtWorks consultant Sarah Taraporewalla has reported her experience with feature branches and feature toggles.
• Adam Dymitruk has a post giving advice on how to make feature branches work for you.
• Jez Humble, author of Continuous Delivery, weighs in with his own point of view.

Make sure you read the comments on these posts to get both sides of the story.

In the software development world in general, and in the agile community in particular, Martin Fowler is pretty much considered the ultimate authority on just about everything. He’s not like Joel Spolsky, who preaches a feel-good message laced with linkbait such as you should invent your own programming language but not use Ruby, or that the SOLID principles are too bureaucratic to be useful. He speaks in measured tones based on years of experience working with large enterprise clients. He (mostly) shuns controversy and focuses on value. He adopts a Neutral Point Of View. He is not just an agile coach, or an agile luminary, he is one of the authors of the Agile Manifesto itself. He has written several ground-breaking books on software engineering, including Refactoring and Patterns of Enterprise Application Architecture. Someone of that stature makes the best of us look like schoolboys in short trousers by comparison.

So when I came across this video of him and his colleague Mike Mason speaking on the perils of feature branches, I was absolutely horrified. Horrified, because much of what they have to say is totally misleading and completely misrepresents what branch-per-feature is all about. It sounds like the kind of anti-branch FUD that I only ever expected to hear from Highly Paid TFS Consultants and vendors of Subversion-based software, who have the most to lose from the next generation of source control tools that make branching and merging safe, robust and easy.

Note first of all what they’re saying.

• They are saying that Feature Branching is incompatible with Continuous Integration.
• They are not saying that you can shoot yourself in the foot if you do Feature Branching wrong, but you can be much more productive if you do Feature Branching right. They are saying that Feature Branching is bad. Period.
• They are not saying that some tools aren’t cut out for Feature Branching but others are, and if you’re stuck with one of the ones that aren’t, here’s how to make the most of it. They’re saying that Feature Branching is bad. Period.

Now maybe they may argue that they don’t actually mean that, or that I’ve misunderstood them, but the problem is that that is what the anti-DVCS scaremongers will hear, and as sure as eggs are eggs, they will milk it for all it’s worth. Certainly, the whole tone of the video towards feature branches is strongly negative. And in some places, factually inaccurate. Besides which, the alternative that they propose is no better.

Feature branches are not about sporadic integration.

Fowler contrasts feature branching with Continuous Integration as if the two are diametrically opposed to each other. He says this:

The cool rule of thumb that I use for Continuous Integration is that everybody’s integrating back to the mainline at least once a day, while with feature branching, people can go for many days, possibly many weeks, until they complete the feature, and then they only integrate once the feature is done. And it’s that frequency of integration which is the key difference.

No, no, no, no, no, no, no! That is not what feature branches are about!

Feature branches are not about increasing the amount of time between integration, they are about decreasing the time between check-ins. You still break down your features into the smallest tasks you can deliver. You still integrate as frequently as you can, yes, at least once a day where possible. The difference with feature branches is that you start checking in code several times an hour. Why? First, this gives you checkpoints that you can roll back to if you discover that you’ve made a mistake, and second, it makes the thinking behind what you’re doing easier to describe and decipher.

The reason why people think feature branches are for long-running epics is because that is the way that old school centralised tools have taught them to think. They’ve made branching and merging hard through poor tooling, algorithm support and architecture, so people do everything in trunk except for epics, then they run into problems and the whole pattern becomes self-reinforcing. Whereas the correct way to do it is to make branching and merging the default option, so people start off with small, frequent merges, and naturally expand into epics as they develop the maturity to handle them.

Feature branches versus Continuous Integration is a false dichotomy. You don’t do either/or, you do both/and.

Semantic conflicts are not specific to branching and merging.

Fowler then goes on to bring up the issue of semantic conflicts.

And the issue here is, yes they can make the problems of textual merging go away, and certainly the textual merging algorithms have improved greatly over the last ten or twenty years, but there’s still semantic issues that go deeper than the pure text, and they, those do not go away, and as a result you still have big, painful merges and the pain increases exponentially the longer you leave between integrations. So by integrating more frequently, even though you’re doing a lot more integrating, the integrations are sufficiently small that they’re not actually causing a lot of problems and as a result you can do them a lot more smoothly as you go along.

I’m sorry, but that is a straw man. Yes, semantic conflicts are a problem, but they are not specific to branching and merging. Any kind of integration will have semantic conflicts. Trunk-based development will have semantic conflicts. A lock/edit/unlock model such as that adopted by Visual SourceSafe will have semantic conflicts. Everyone editing the same files directly on the same server and not using source control at all will have semantic conflicts. Semantic conflicts are a fact of life no matter what integration model you use. Get used to it.

Besides, the integrations where you need to worry most about semantic conflicts are not the biggest, scariest ones. By the time you get to that level, you are looking at textual conflicts all over the place anyway, so you’ll be on your guard and double checking everything. The semantic conflicts you need to worry about are the ones where there are no textual conflicts at all, where you have dropped your guard. In other words, the size of merges that are typical of Continuous Integration. In any case, we have tools to deal with them. They are called compilers, static analysis, and unit tests. As for any that slip through that net, all you can do is treat them like any other bugs. The question here is, how many of these semantic conflicts translate into new bugs and regressions in your code compared to bugs introduced through any other means? When you are used to feature branching, that is exactly how you view semantic conflicts: as no greater or less a deal than any other form of bug.

For what it’s worth, semantic conflicts have been the subject of some academic research, for example, in this paper, which is well worth a read for anyone who is concerned about them, their prevalence, the risks that they may or may not pose, and strategies to mitigate their effects. But it would be naive and wrong to be paranoid about feature branches because of them, because, as I said, they can crop up just as easily in trunk-based development.

Feature toggles can cause problems too. Bigger, scarier problems.

Feature toggles are a way of avoiding branching and merging, which Joel Spolsky describes as “a workaround for the fact that your version control tool is not doing what it’s meant to do.” Branch by Abstraction is much the same thing, except that it uses IOC containers instead of if statements. Mike Mason explains it as follows:

So, feature toggles are a mechanism whereby you implement a new feature, but simply have it switched off, usually in the software configuration, and in most systems that can be as simple as not including a feature in the UI, so it’s actually being developed under the covers, it’s present in the source code, but you don’t enable it in the UI so nobody actually sees it.

You see what the problem is here? And man, it is a massive problem—visible or not, you are still deploying code into production that you know for a fact to be buggy, untested, incomplete, and quite possibly incompatible with your live data. Your if statements and configuration settings are themselves code which is subject to bugs—and furthermore can only be tested properly in production. They are also a lot of effort to maintain, making it all too easy to fat-finger something. Accidental exposure is a massive risk that could all too easily result in security vulnerabilities, data corruption or loss of trade secrets. Your features may not be as isolated from each other as you thought they were, and you may end up deploying bugs to your production environment. I’m not speaking theoretically here either: this has actually happened to me. Unless your feature toggles are well bedded in, and you have some pretty mature processes and infrastructure in place to manage them, you’re asking for trouble. Certainly, my own experience of them has been uniformly negative.

But wait! He actually goes on to acknowledge these concerns, albeit in drastically watered down and sugar-coated terms compared to the sheer FUD that gets spouted against feature branches:

The traditional concern with that approach is that you’ve got a half finished feature in your codebase, so OK it’s not visible in the UI, but you made some changes, surely you may have broken something? And the right response to that is to have confidence in your automated testing that you should also have, to guarantee that even with a half-finished feature that’s hidden with a feature toggle, you haven’t broken anything else.

Right. So, after having given us no guidance whatsoever on how we can use feature branches responsibly and effectively, they then go on to give us guidance on how to responsibly use what is, when it boils right down to it, a high-risk, high-maintenance hack. If that isn’t a lopsided view of the subject, then what is?

In fact, they go on to talk about one case where the client had so many feature toggles that they needed to have their own custom compilation of the Linux kernel just to handle them all. But oddly enough, they don’t translate that into “feature toggles considered harmful” in the way they do for feature branches.

For what it’s worth, this highlights a problem with the very idea of Continuous Integration itself.

Continuous Integration is largely a workaround anyway.

It seems that all the FUD about feature branches boils down to one thing: we should restrict ourselves to trunk-based development because Continuous Integration is the One True Way to do configuration management. But let’s just take a step back and ask ourselves why we do Continuous Integration in the first place? Largely because we were restricted to trunk-only development. If you check in code that breaks the build, then go home, and then someone else checks it out, they can’t get anything done till you return and fix it. You constantly need to have a ready-to-deploy version of your code in case of security vulnerabilities. While this isn’t the whole picture, and there are other arguments in favour of Continuous Integration, it is at least partly a hack to work around the restrictions of trunk-based development. The vagueness of Martin Fowler’s “cool rule of thumb”—that you should check in “at least once a day” is testimony to this. Cargo culting your way through advice like that will lead to you checking in incomplete, buggy or even downright broken code, and the need for high-maintenance hacks such as feature toggles to compensate.

A hack to work around the limitations of another workaround for the limitations of our tooling. All this being lauded as a best practice. What on earth is the world coming to?

But these restrictions don’t apply to DAG-based tooling, where you can easily base your work off the last known good revision. Yes, you can end up with conflicts when you branch and merge, and yes, you can easily shoot yourselves in the foot if you’re not careful, and yes, you can end up with Big Scary Merges, but with good communication and planning among developers, many teams can—and do—easily and confidently handle surprisingly long-running branches with few if any problems. And yes, you should be keeping your work items as small as possible so that you can integrate as frequently as possible. Yes, feature branches get misused. But the correct response to misuse is not disuse, but proper use.

The most dangerous factor in this matter, however, is Martin Fowler’s reputation. Many agilists view him as infallible when speaking ex cathedra on matters of architecture and methodology, and for him to promote points of view such as these is to hand ammunition to the anti-DVCS lobby on a plate. Were this to lead to a wholescale rejection of feature branching and distributed source control, it would set the entire agile movement back several years, and that would be very sad.

What is really needed is a holistic, unbiased review of both feature branches and Continuous Integration, to see how we can use feature branches responsibly, and at the same time how Continuous Integration and Continuous Delivery can best be adapted to take them into account. But simply insisting on hanging onto the established ways of doing things with complete disregard for new and better technology is cargo cult programming, and it certainly isn’t agile.

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.

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.

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.

In the eighteen months since I started using KeePass to manage my online passwords, I’ve found that it involves a certain amount of friction. For starters, it’s less user-friendly. Rather than just typing your user name and password straight into your browser, you have to switch to the KeePass window, find your website, and then paste. There are shortcut keys and a search facility to make things easier, but it is a bit of a learning curve. Furthermore, when you register with a new site, you have to fiddle about with the password generator in order to create a new password, and on top of that, some websites have undocumented limitations or bugs in their password forms. One well known website that I use allows you to set passwords of any length, but limits you to 20 characters in the login screen, for example.

That’s a relatively minor complaint, of course. A much more serious difficulty is synchronising passwords between different devices, not all of which may support your password manager of choice. KeePass for the iPhone is not yet available outside the USA and Canada, for example. Third party password managers may not even be an option on certain other Internet-enabled devices such as the PlayStation, Internet TV, and so on. Then there are situations such as a friend’s computer when you don’t have your password database on you; Internet cafes and kiosks; and locked-down workstations on corporate networks.

Clearly, avoiding password reuse requires a certain amount of discipline, sacrifice, and technical know-how. Even many relatively tech-savvy users view it as one of those things that “I must get round to someday” — a bit like taking up exercise or flossing your teeth. So where does that leave your non-technical users?

The overwhelming majority of non-technical users are shockingly ignorant about even the most basic aspects of web use. A couple of years ago, Google interviewed passers-by in Times Square, New York, and found that more than ninety percent of the people they stopped didn’t even know the difference between a web browser and a search engine:

The upshot of all this is that as a data controller, it is totally unrealistic to expect your users not to re-use passwords. They shouldn’t re-use passwords, and they should use a password manager, and they should choose secure passwords, and you should warn them of the risks. But to many of your users, if you try to explain the risks to them and what to do about it, their eyes will just glaze over and they will say to you, “Oh, I’m not a computer person. That’s all too technical to me.” They will re-use passwords. In so doing, many of them will entrust you with the login details to their e-mail, Facebook, PayPal, and possibly even their bank accounts. They shouldn’t, but they do. And with that in mind, you have a responsibility to do everything in your power to protect those details.