james mckay dot net

A couple of blog posts caught my attention over the weekend. The first was from Robert Scoble, attributing MySpace’s woes, at least in part, to their choice of technology stack. The second was from David Barrett, the CEO of Expensify, explaining why he doesn’t hire .NET programmers.

Now there is the saying that a bad workman blames his tools, but there is such a thing as a bad tool (would you want to use a hammer whose head keeps flying off?) and having had fairly extensive experience of both .NET and other technologies, I could say that they both have a point, and it’s a point that I’ve personally found increasingly frustrating over the years. Specifically, I’ve noticed the following:

1. I find it significantly easier to be productive with Python or PHP than with .NET.
2. When I’m working with .NET, I find it significantly easier to be productive with client-side JavaScript and HTML than with C#.
3. By far the biggest productivity killer in .NET is the edit/compile/test loop.

Here’s the difference. When you’re working in an interpreted scripting language such as PHP, Python or JavaScript, making changes is simple and fluent. You edit some code. You run your tests, or hit F5 in your browser. You see the results of your change almost immediately. Lather, rinse, repeat.

On the other hand, in .NET, once you edit your code, you have to re-compile your project. If your change is to the front end of your code, such as a tweak in your .aspx page, this might not take long. But if you are making changes in the back end, it can take a sizeable fraction of a minute. Then you have to re-load your project, with all its dependencies, into memory. For a large project, with a lot of dependencies, this can take a minute or more. And of course, that’s assuming that Visual Studio doesn’t freeze altogether in the process, which it very often does.

Now here’s the killer. Increasing the feedback time from ten seconds to over a minute knocks you right out of the zone. When you get quick feedback, you remain fully engaged, and fully focused on the task at hand. On the other hand, when you have to sit and twiddle your thumbs, it becomes increasingly difficult to resist the temptation to go and get yet another cup of tea, or switch to something else and get distracted. Even if you don’t, you still have to pick up the threads of what you were thinking about before you started. It can easily make a difference of an order of magnitude in productivity if you’re not careful, and even if you are, it’s still pretty wearying.

Incidentally, Joel Spolsky makes exactly this point in the Joel Test when advocating quiet working conditions and the best tools that money can buy.

However, it isn’t always possible to avoid .NET altogether: to do so would be to cut yourself off from a lot of opportunities, and I’m certainly not ready to throw in the towel yet and switch completely to Ruby on Rails, as some people do — noisily. So, that being the case, what can you do to alleviate the situation?

Here are some suggestions worth considering:

• Use a lightweight text editor such as Notepad++ or vim alongside, or perhaps even instead of, Visual Studio. Yes, you lose IntelliSense and integrated debugging, but this forces you to rely more on test-driven development, commit the APIs that you use to memory, and get into the habit of paying more attention to detail, and that only benefits you in the long run. Besides, that’s how we code in other languages, and we’re none the worse for it. As long-time Windows programming expert Charles Petzold will tell you, IntelliSense and integrated debugging dumb you down.
• Have as few projects in your solution as possible. Lots of projects mean lots more dependencies have to be loaded, and that can dramatically increase compilation times. Also, keep your layers of abstraction to a minimum.
• Alternatively, if you genuinely need a lot of projects, use more than one solution. That way, you reduce the risk of accidentally triggering an unnecessary “Rebuild all.”
• Resharper is great, but I’ve found it uses a lot of IDE resources and increases the risk of freezes. Unless you have plenty of memory (like, 8GB or more) at your disposal, consider turning it off.
• Disconnect from the Internet when you need to focus on what you’re doing.

Comment on this »

Posted at 08:00 on 28 March 2011.
Tagged: .NET, productivity

There seems to be a common misconception among some Git users that in order to branch your code in Mercurial, you have to clone your repository. While some Mercurial users prefer to work that way, it isn’t actually necessary, and Mercurial does provide you with a much more lightweight alternative. The easiest way to branch your code is simply to hg update to the revision off which you wish to branch, then when you next hg commit, it will implicitly create a new branch for you. Similarly, when you hg merge, it will implicitly close the branch off. I tend to use a mixture of the two approaches, with repository clones for longer-running feature branches, and in-place branching for ad-hoc experimentation, smaller features, and the like.

A lot of confusion seems to centre round the concept of named branches though. If you’re used to the way Git works, you’d be forgiven for thinking that pulling from a remote repository would replace your “foo” branch with the incoming one, sending your work off to be garbage collected unless you merge immediately after pulling. Mercurial doesn’t actually work that way — what you get is two parallel branches, both called “foo”, which you can then merge, rebase or strip out as appropriate. This is because Mercurial tends to view the DAG as more immutable than Git does, and if you want to remove branches that are no longer needed, you do it explicitly using hg strip (a part of the Mercurial Queues extension).

For what it’s worth, I don’t like the way Mercurial uses the word “branch” here, since it doesn’t accurately reflect what you expect the word “branch” to mean: a single code line where every node in the DAG has exactly one parent and exactly one child. It seems to me that it’s something of a leftover from centralised, line-based tools such as Subversion and Perforce, where every branch has to have a name because of the need to place it somewhere in the file system.

But I don’t find it a big deal. I find the best way to handle branching and merging in Mercurial is to view your branches as essentially anonymous. Branch names, tags and bookmarks then become purely a documentation layer added on top of the DAG. I personally view branch names in particular as largely vestigial and almost never use them — I always commit exclusively to default, and generally recommend others to do the same unless they have a valid use case for them. If you need to keep track of which head is which, the bookmarks extension provides similar functionality to Git branches, and is far less confusing.

Incidentally, one DVCS that does seem to require you to clone your repository in order to create a new branch is Bazaar. I’ve spent a few hours tinkering with Bazaar on and off over the past few months and I haven’t yet been able to find a way to branch in-place similar to hg update/edit/hg commit or git branch. Perhaps someone could enlighten me?

Comments (2) »

Posted at 08:00 on 22 February 2011.
Tagged: Mercurial

Now if you start getting symptoms that make your heart miss a beat, it’s tempting in these days of instant information to turn to Google. Or Wikipedia.

Don’t do it!

I’ve learned this the hard way the past couple of months. Some of the symptoms I’ve been getting during and since my recent particularly nasty bout of flu have made me wonder whether there was something serious going on.

So I went to Google, typed in my symptoms, only to be led to various articles that told me I could drop dead at any moment. I turned to Wikipedia, and the information it presented from Reliable Sources told me exactly the same.

Then yesterday I saw my doctor and he told me that this is unlikely. In fact, he was quite firm that he doesn’t think I have any significant, immediate, life-threatening concerns. He wants to do some tests, but he put me at ease about everything. He’s good at that.

If you’re worried about your health, avoid Google. Avoid Wikipedia. Go to your doctor.

Your doctor knows your medical history. He knows what you actually have. Google doesn’t. Google only knows what you think you have, and even then, it conflates that with things that your loved ones have, things you think your loved ones have, things you think your favourite celebrities have, and things that the characters in the novel that you’re trying to write think they have. Google will lead you onto discussion forums frequented by (a) people who actually do have significant, immediate, life-threatening concerns, (b) people who haven’t a clue what they’re talking about, (c) conspiracy theorists, and (d) spammers.

Google will present you with scare stories about misdiagnoses that make you mistrust your doctor. While these are tragic, they are very much the exception rather than the rule, and they only make the headlines because they are unusual.  Google will lead you to articles presenting worst-case scenarios alongside everyday ailments that can be treated with over-the-counter remedies. Google will present all this to you in a blunt, deadpan, just-the-facts-ma’am manner. You’ll end up diagnosing yourself with mutually contradictory disorders. And then, to add insult to injury, for the next three weeks, every website you visit will carry adverts for quack remedies for syndromes that kids you don’t have don’t have.

Your doctor, on the other hand, will filter out all the irrelevant stuff for you. He won’t tell you about incurable life-threatening diseases when all you have is Team Foundation Syndrome, which can be easily treated by switching to Mercurial. And because you are in a face-to-face interaction with someone who is trained to help worried people, and you have the non-verbal communication element, even if the news is bad or esoteric, it will be easier to handle.

If you want an online resource that can give you advice on what to do, go to a site such as the NHS symptom checker. It will ask you a series of questions about your symptoms, and based on your responses, it will tell you whether to call an ambulance, go to the chemist for an over-the-counter remedy, or see your doctor.

Comments (1) »

Posted at 08:00 on 16 February 2011.
Tagged: Google, health

tl;dr: Advocates of Team Foundation Server, Microsoft’s ALM suite, respond to criticism by saying that TFS is not just source control but an end-to-end integrated ALM suite. This completely misses the point of our criticism of TFS in the first place: that we find it restrictive, bureaucratic, unreliable, and extremely difficult to use. End to end integration does not justify unreliability or a poor user experience.

About a year ago, Martin Fowler conducted a survey of ThoughtWorks developers to find out what they thought about various source control tools. Not surprisingly, Git came out top. The one that came out bottom? Team Foundation Server. In fact, TFS was unique in getting no positive responses at all: out of 54 respondents who had used it, every single one of them rated it as either “problematic” or “dangerous.”

Team Foundation Server advocates claim it’s unfair to compare TFS to other source control tools, since it’s not just source control, but an integrated end-to-end application lifecycle management solution. Comparing TFS to, say, Subversion, is like comparing Microsoft Office to Notepad, so they say.

Now where have I heard something like that before? Oh yes, Lotus Notes:

The main focus for frustration is Notes’s odd way with email, and its unintuitive interface. But to complain about that is to miss the point, says Ben Rose, founder and leader of the UK Notes User Group (www.lnug.org.uk). He’s a Notes administrator, for “a large automotive group”.

“It’s regarded by many as an email program, but it’s actually groupware,” Rose explains. “It does do email, and calendaring, but can host discussion forums, and the collaboration can extend to long-distance reporting. It will integrate at the back end with huge systems. It’s extremely powerful.”

The thing is, it wasn’t the detractors who were missing the point. It was the Lotus Notes guys. You see, e-mail is right at the heart of any groupware application. It’s the part of the application that users interact with the most. It’s where usability matters the most. And it’s what Notes got wrong the most.

It’s exactly the same with ALM tools. Source control is the part of your ALM tool that is most visible to developers. It’s source control rather than, say, work item tracking or continuous integration, that can make or break your workflow. It is source control where a zero-friction experience is most important.

Team Foundation Server is not zero-friction. Not by a long shot.

I guess if you have only ever used TFS, Visual SourceSafe, and perhaps exclusively trunk-based development in merge-paranoid Subversion teams that use if statements and configuration settings to avoid branching, you would be happy enough with it, since that’s all that you know source control to be capable of. But once you’ve actually used one of the alternatives that offers you fluent, unrestricted branching and merging, a local sandbox, flexible workflows, self-consistent best practices, and source control as an extension of your undo button, the limitations of TFS become so massive that it’s not even funny any more. (Incidentally, if you tot up the figures in Fowler’s survey, you’ll find that his respondents had, on average, experience with six different tools.)

But even if you’ve never used a DVCS and are only comparing it to Subversion, it’s still a usability disaster. Subversion may have pitfalls and gotchas and limitations of its own, but once you know your way around it, you can at least work as fluently with it as is possible with a primarily trunk-based, centralised tool. In TFS, even the simplest tasks become Herculean undertakings. How do you back out a changeset that isn’t the latest, for instance? Why can’t I have a check-in screen that shows only the files that have actually changed since my last commit? Why does it take me half a dozen mouse clicks for each file in my check-in screen to find out that it doesn’t have any changes? Why is it asking me to check in files that don’t have any changes in the first place? Why does it turn Visual Studio into a Berlin Wall around my code with these awful read-only files? Why does it lobotomise the branching and merging experience with baseless merges, making feature branches — pretty much a must-have for a pain-free ALM experience these days — impractical for all but the largest tasks? Why can’t it cache my login credentials to a server on a different domain like Subversion does? Why does the command line interface bring up dialog boxes? Is it a command line interface or isn’t it? And that’s barely scratching the surface of its usability problems. It doesn’t even have a search tool to speak of.

Furthermore, the source control component is the one part of TFS that you can’t swap out for something else. You can use TFS source control with Trac, Mantis, FogBugz or Jira, or with TeamCity or FinalBuilder, but you can’t use TFS work items or TFS build servers with Subversion, or Git, or Mercurial. As far as TFS is concerned, source control is their way or the highway.

End-to-end integration is all very well, but it is hardly a killer feature, and when the most visible component that it integrates is difficult to use and gets in the way, it ceases to be an asset and it becomes a liability. It’s far better to have a selection of separate tools, each of which is designed to do its job well, than a single monolithic application that does everything badly.

Comments (39) »

Posted at 08:00 on 14 February 2011.
Tagged: source control, TFS

There’s a lot of confusion among developers about how often to check in code to source control. Many projects have histories riddled with huge commits making sweeping changes to dozens of files, often with only a vague commit summary or even no commit summary at all. Those projects that have guidelines and policies in place usually don’t have a clear justification for those policies, and some of them are downright unhelpful, such as, “at least once a day,” or “whenever you come to a natural break in your workflow, such as lunchtime.”

The problem is that if you’re all doing everything in a single branch, typically trunk, it is not possible to come up with a straight answer to the question.

Should you check in early, check in often, as Jeff Atwood once described as the golden rule of source control? This ensures that you never lose much code, you keep up to date with everyone else, and you don’t go dark. However, if you’re all working on different tasks on the same branch, you will end up with two sets of unrelated revisions tangled up together in your history, and if one needs to go live, like, yesterday, and the other has had to be put on hold for any reason, as happened to us at the end of our last sprint, you’ll run into difficulties.

Alternatively, you could check in only completed units of work. However, this causes other problems. Deferring check-in until a unit of work is complete often results in huge, monolithic commits that increase the risk of integration conflicts. Furthermore, if you get into a mess attempting to resolve said integration conflicts, there is no way to back out to where you were before you ran svn update. I’ve had colleagues in this situation end up with no option but to roll back to the latest revision in source control, losing days of work that only existed in their working copy in the process.

Furthermore, large, monolithic commits are impossible to describe comprehensively and accurately in a commit summary, and they cause problems when carrying out a binary search of your history for the revision that introduced a bug.

Of course, you should be dividing your work up into smaller units as much as possible anyway to minimise the risk of this happening, but this isn’t always possible. Whichever of the two options you choose, you’re going to run into problems sooner or later.

Having a separate branch for each feature resolves this dilemma neatly. This sounds scary at first if you aren’t used to branching and merging, but providing your tooling supports it, it isn’t as bad as it sounds, since feature branches are usually fairly short, so you don’t get as many Big Scary Merges as you would expect. Besides, even when you do get a Big Scary Merge, it’s better than an otherwise identical Big Scary Commit, because if your attempts to resolve the conflicts go wrong, you can at least roll back to what you had before you attempted the merge and try again.

With that in mind, we can come up with some more sensible guidelines on how often to commit to source control.

1. Every commit should serve one, and only one, purpose.

This is a straightforward corollary to the Single Responsibility Principle. If you have to use the word “and” or “also” in your commit summary, you’re probably checking in too much.

If you have two unrelated changes in your working copy, you need to break them up. This is called the “tangled working copy problem,” and modern SCMs give you tools to sort it out. If you’re using Subversion or TFS, on the other hand, well, you should have been more careful. Unfortunately, it can be pretty hard, or in some cases even impossible, to avoid.

Needless to say, you should never check in code to two separate branches, let alone to two separate products, in a single commit, even if your source control allows you to do so.

2. Every commit should be small enough to be described in detail in the summary.

Your commit message won’t necessarily cover every last line of code in your change. If you’ve added a whole bunch of stuff, as long as it’s reasonably self-explanatory and isn’t riddled with meaningless method names such as doIt(), a single line commit message may suffice. But the combination of your code and your commit message should explain every line that has changed. And if you’ve removed or edited existing code, that will all need explaining in your commit summary too, particularly if it’s counterintuitive or at first sight could be mistaken for a bad practice, such as changing an encoding from UTF-8 to 7-bit ASCII.

If your commit is too large to make this practical, your commit is too large, period.

3. Every commit should build and (usually) pass all your unit tests.

Some DVCS users may disagree with me on this one, insisting that you can use your local history as a sandbox for your commits, so it doesn’t matter, but I stand by it. Broken builds have to be marked as untestable by your bisect tool, which complicates pinpointing the change that introduced the bug. A string of broken builds in succession makes matters worse. Besides, both Git and Mercurial provide mechanisms to allow you to resolve this situation by combining breaking changesets with ones that fix them — namely, interactive rebase (or git commit --amend) and Mercurial Queues respectively.

The only exception to the rule that every commit should pass your unit tests is when you are working in a test-driven manner, where you write a failing test then write code to make it pass. Here, you may want to consider checking in the new test separately from the code to fulfil its requirements, in order to audit just how test-driven your development really is.

4. Use feature branches liberally, and merge to your main development branch only when the task is complete.

This guideline is a more sensible version of “check in only completed units of work.” Single-responsibility, easily describable commits are obviously fairly small and frequent (a few lines of code, representing less than an hour’s work), and usually do not represent a completed unit of work.

That’s why feature branches are so important if you are to observe best practices with source control. In this case, “check in only completed units of work” becomes “integrate only completed units of work,” and the conflict between the two different best practices is thereby resolved. When you merge, always say what you are merging, with an issue number in your bug tracker where appropriate. Don’t just write “Merge.”

In an ideal world, every feature should be developed on a separate branch. With a modern DVCS, this is of course the default, and very easy. With centralised source control, however, it can take considerably more effort depending on your tool and your project setup, but it is by no means impossible. In cases such as these, you may need to make some compromises, and decide on a threshold above which to create a feature branch. But in general, it’s best to keep this threshold as low as you can get away with, or possibly even lower it gradually as you and your team-mates become more confident with branching and merging. Certainly, if you’re doing exclusively trunk-based development, you’re denying yourself a straight answer to the question of how often to check in code, and asking for problems sooner or later. Whatever SCM tool you are using, if you don’t know how to branch and merge with it, you should learn how to do so.

Comment on this »

Posted at 08:00 on 7 February 2011.
Tagged: source control

Those of you who follow me on Twitter may have noticed that I’ve been working on a photoblog in my spare time over the past couple of weeks. This is part of my New Year’s Resolution to revive my interest in photography, and take at least one photo a day worth posting on it. I’m hoping that this will (a) force me to get out from behind the computer and find some other activities worth photographing, and (b) help me to improve my technique.

I only got started in mid-January, thanks to the flu, but my photoblog finally went live at the weekend, and the results are now up there for you all to enjoy.

Taking a photo that’s worth posting every single day can be really, really difficult at times. Sometimes an inertia sets in, or I don’t do anything worth photographing, or I’m just too busy, or the weather’s excruciatingly naff and I just haven’t got the hang of taking photos of excruciatingly naff weather yet. On days like that, it’s easy to end up posting something a bit banal. But there are other days that present the opposite problem: I end up with several that I like, and have to pick one.

This is one of the advantages of working for the Houses of Parliament. You are right on the doorstep of a wealth of photo-opportunities, and because that part of Westminster is the mother of all tourist attractions, everyone else is taking pictures left, right and centre too, so you can go for a walk at lunchtime and snap away to your heart’s content without feeling self-conscious about it.

On Friday, for instance, I did just that, and ended up with no less than four candidates for photo of the day. The first was this one from the Lambeth Bridge, looking towards Vauxhall. The lighting conditions were interesting enough to have some fun with, and I managed to get a particularly moody feel by underexposing it by one stop:

Then a few minutes later, in the subway underneath the east end of Lambeth Bridge, I caught this silhouette of a jogger running out into the light. It stands out because it’s the kind of place where most people never think of taking photos, but it’s also a bit of a “decisive moment” picture:

Over on Westminster Bridge, I was particularly struck by the sunlit London Eye against a backdrop of cloudy skies:

But in the end of the day, the one I liked the most from my half hour photowalk was this one of the protest camp in Parliament Square. Whatever you think of the politics or the aesthetics of their campaign, there’s no denying that their Tardis is a work of art:

I wonder if it’s bigger on the inside than on the outside?

Comment on this »

Posted at 08:00 on 31 January 2011.
Tagged: London, photography

My New Year’s Resolution this year was to revive my (admittedly somewhat dormant) interest in photography. I’ve set myself a goal of taking at least one photo a day worth posting on a photoblog (currently under development). At this time of the year, dull weather and dark mornings and evenings make that a little bit difficult, especially if it’s natural light photos that you’re after, but it does give me rather more scope for experimental photography — the kind of thing that you might see in the Tate Modern alongside cows in formaldehyde, piles of bricks, and Globus Cassus. Experimental photography is particularly good fun because it’s…well, experimental.

When I first took up photography in the mid-1990s I occasionally came in for a bit of a ribbing from my family about some of the more experimental photos that I would take. To them, photography meant just quick snaps of family and friends, to preserve memories, and anything else was a waste of film. They had a point there — the cost of film was an issue, so there were obviously budgetary restraints on just how much experimenting I could do.

These days, of course, since it’s all digital, the cost of film and processing is no longer an issue, so you can experiment to your heart’s content. The other night on the way home from the station I strapped my point-and-shoot digital camera to the handlebars of my bike and pressed the shutter every time I was overtaken by a car — just to see what the result would look like. Out of the dozen or so pictures that I took, most of them didn’t show anything worth reproducing, but sure enough, there were one or two rather interesting specimens:

I’ve called this one “Light scribbles” and it’s now my new Windows desktop wallpaper.

Comments (2) »

Posted at 08:00 on 27 January 2011.
Tagged: photography

Mercurial’s bisect command is a fantastically useful tool when you’re faced with a bug.

It’s a very simple idea. You start off with your latest revision, which you know has the bug, go back to a revision that you know didn’t have the bug, and do a binary search until you find the revision that introduced it.

So let’s say your latest revision was number 500. You’d mark that one as bad, then test, say, revision 100, find that it works as expected, and mark that as your last known good revision. Mercurial will then automatically update to revision number 300 (halfway in between) for you to test. Mark as good or bad as appropriate, lather, rinse and repeat until you find the change that introduced the bug.

With every test that you make, the difference between the “good” and “bad” revisions decreases by a half, quickly narrowing the gap:

Consequently you will be able to pinpoint the breaking change after approximately log₂ n tests, so a thousand revisions would only take one more test than 500, and a million would only take one more test than 500,000. Once you’ve found the offending change, you can very easily zoom right in on the problematic lines of code, rather than having to spend ages stepping through it all in the debugger.

You don’t need to be using Mercurial to apply this technique. You can do it manually with any version control tool, though you will need to keep a manual note of what’s what if it doesn’t provide you with the necessary tools to do it. It can also be pretty slow with centralised tools, since you have to hit the network for every test.

There are a couple of points to note with this procedure however.

First, bisect is most effective when your revisions are small and serve a single purpose. If the breaking revision changes a lot of code, and tackles too many things at once, it may be difficult to identify the source of the problem once you have located the offending change. This is why it is important to “check in early, check in often.” This is also why good, informative commit summaries are important.

Second, remember that you’re looking for the revision that introduced a specific bug. If a revision does not have this specific bug but has other problems, you should mark it as good nonetheless.

Revisions that don’t compile, or have other problems that prevent you from determining whether the bug exists in the first place, should not be marked as either “good” or “bad” but should be flagged to be skipped. In this case, your “last known good” and “first known bad” revisions won’t be updated, and the number of tests you have to make will increase, slowing down your search. Consequently it is good practice to ensure that every commit that you make to source control should build correctly and ideally also pass all your unit tests where possible. When you’re using a DVCS it can be tempting to disregard this altogether, but if hg bisect reports that your error is somewhere in a string of twenty successive revisions, none of which compiles, you’ll have more of a headache sorting out what’s what. Certainly, broken check-ins should be very much the exception rather than the rule.

Comment on this »

Posted at 08:00 on 21 December 2010.
Tagged: debugging, Mercurial, source control

We’ve been using Planning Poker for a couple of months now in our sprint planning meetings, and on the whole it’s been quite a success. If you’ve never come across it before, Planning Poker is an estimation technique that’s been gaining popularity among agilists recently: it’s not only surprisingly easy and accurate, but it’s also really good fun.

The procedure is as follows. Each participant is given a deck of numbered cards in the first few elements of the Fibonacci series: 1, 2, 3, 5, 8, 13, and so on. One developer chairs the meeting, and a project manager comes along to explain the requirements for each task that needs to be tackled. The developers then discuss what is involved and break the task down into sub-tasks.

Once the task has been broken down in this way, each sub-task is taken in turn. Every member of the team selects a card indicating how long they think it will take (in our team, we measure it in hours, though some teams use somewhat more vague units of measurement). They place it face down on the table, then once everyone has selected their estimate, they all turn their selected cards face up at the same time.

Sometimes, there will be a consensus; on other occasions, there may be one or two dissenters from the majority opinion. In this case, the dissenters are asked to justify their estimates to the rest of the group. If the estimate comes to more than eight hours, the group then further divides that subtask in to smaller tasks.

The “poker” element is a great leveller. It means that the discussion isn’t dominated by the most dominant, or the most senior, member of the group. It means that the introverts are brought into the discussion. But there are some points that some people seem to have difficulty understanding.

First, proposing actual estimates while breaking down the task is strictly forbidden. The time to make your estimate is when you come to put down your card, not before. There is a good reason for this: if you start quoting figures, you will be “anchoring” the estimate and influencing your team mates. Even if they consciously ignore what you have to say, they may subconsciously alter their estimates to bring them into line with yours, whereas they may otherwise have taken into consideration factors that you hadn’t thought about. Of course, if you actually want to influence your team mates in their estimates, you have no business whatsoever doing so. The idea of planning poker is that estimates should be made on the basis of evidence, not subjective opinion. If you do have a strong opinion that differs from the team consensus, you will be given a platform to justify it after everyone has revealed their cards.

If people persist in proposing estimates prematurely, it might be a good idea to institute a “penalty box” into which offenders would be required to forfeit, say, 50 pence per violation, which could then be donated to charity.

Secondly, don’t get too hung up on the accuracy of your estimates. Planning poker uses the Fibonacci sequence for a very good reason: your estimates will be subject to an uncertainty of perhaps 50% or more. Some estimates will be too small and others will be too large, so in the end of the day it will all balance out. Four is not an option because it is well within the uncertainty range of both three and five. Similarly, don’t get into an argument about it: that just wastes time. Besides, if you can’t come to a consensus for a task within about a minute or so, you’ve probably not broken it down clearly enough.

Finally, even if the details are wrong, the estimate may still be right. A few weeks ago, our team estimated for one particular task using Planning Poker when I was on holiday. Since I had the necessary domain knowledge for this particular task, I ended up working on it when I returned. They got the implementation details of the task concerned completely wrong when estimating, but incredibly, the time that I took to complete it turned out to be within about five percent of what was estimated.

Comment on this »

Posted at 08:00 on 16 December 2010.
Tagged: agile, estimating, planning poker

About a month or so ago, elite C# gurus such as Eric Lippert and Jon Skeet were discussing the new async and await keywords that are forthcoming in C# 5. Eric Lippert introduced them with a series of blog posts on continuation passing style programming that I haven’t yet got round to reading properly.

People who are into continuation passing tend to wax lyrical about it, portraying it as the latest cure for cancer. But I’m wondering just how much of my time I should spend on it. To me, it looks a bit whacked out — isn’t it just some kind of nonlocal goto, and aren’t goto statements considered harmful? How will it help me write code to keep the Great British Public informed about what their elected representatives are discussing in Select Committees?

You never know. No doubt in a few years’ time, I too will be passing continuations around like sweets at a children’s party. I had similar thoughts a few years back when I first read about LINQ. Why would anyone want to embed SQL statements in their C# code, I thought? It sounded a bit like the bad old days of tag soup in classic ASP. But nowadays I use LINQ all the time and I’ve long since figured that LINQ is not LINQ to SQL. In fact, I don’t see how you can get anything done without LINQ. It’s just so much cleaner than writing a whole bunch of for loops. And it gives you lazy evaluation, which can give you massive performance benefits if you use it properly.

This is a common paradox in programming. Once you get to grips with a new programming language feature, concept or tool, you wonder how on earth you managed to write any code at all without it. But on the other hand, when you look at all the concepts, features and tools that people are waxing lyrical about in those terms, they all look weird, if not completely scary. And when you wax lyrical about something or other, as sure as eggs are eggs, someone will tell you your tool is the weird and scary one.

In his essay, “Beating the Averages,” Paul Graham calls this the Blub Paradox:

Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn’t use either of them. Of course he wouldn’t program in machine language. That’s what compilers are for. And as for Cobol, he doesn’t know how anyone can get anything done with it. It doesn’t even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn’t even have y.

I guess the best definition of “Blub” is the collection of programming language features, concepts and tools that you know and understand — or at least, that you can see might come in useful, so you really ought to get round to learning about them. It’s what makes sense from your vantage point. But when you look up and see someone waxing lyrical about something unfamiliar, don’t just write it off as weird. They may quite possibly be right.

Comment on this »

Posted at 08:00 on 13 December 2010.
Tagged: jargon