Because I know I’ll forget where I found these things (despite having added them to Delicious), I figure I should add them here.
A hand of Planning poker cards
For those who are unfamiliar with the concept, Planning poker is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development. In Planning poker, members of the group make estimates by playing numbered cards face-down to the table instead of speaking them aloud.
Once everyone has played a card, the cards are revealed and the estimates are discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.
I’ve just mailed round my team and asked them to install the Android or iPhone app, so we can use Planning poker in an estimating session I need to run soon.
The photo of a Planning poker set used in this article is taken from the Wikimedia Commons and was released into the public domain by its author, Wikipedia user Hkniberg.
Some things I need to remember about working in a deadline-based industry. (This will probably be one of many posts on this subject during the current big-build project.)
- If you don’t push back when you have too much on, people will assume you can manage it all.
- People don’t mind when you do push back, provided you’re clear and transparent. Being able to suggest when you could get something done, or who else might be able to do it, is merely a bonus.
- If you have something to focus on and get regular interruptions from people, let them know in advance when you’re going to be busy. Manage them and you won’t need to manage yourself.
- You might be snowed under but, if you’re feeling overwhelmed, taking 5 or 10 minutes to sit somewhere quiet and do something unrelated (like reading about volcanoes) makes a whole world of difference to how productive you’ll be afterwards.
- When building websites for a living, no matter how badly things go wrong, it’s a near certainty that no-one will die as a result.
You know all these things, Owen. For gods’ sake, remember them!
The photo of a Japanese Zen garden used above is taken from the Wikimedia Commons and is dual-licensed under GFDL 1.2 and CC BY-SA 3.0 Unported.
I posted a blogpost to Facebook on Saturday entitled “Dear ICO: This is why web developers hate you“. My comment on the post read as follows:
Excellent rant explaining why the EU Privacy Directive (the “Cookie law”) may well suck (which it does — it’s a fucking stupid piece of legislation that should never have been passed) but it’s the ICO who’ve made the Internet industry’s lives hell of late. Sheer simple incompetence.
I’ve had two comments on that post thusfar, one from a friend and ex-colleague who works in the Internet industry in a similar fashion to me — he’s Director of User Experience at a software consultancy. Francois broadly agreed with me:
We are amongst the many, many agencies who spent days and lots of our clients’ money designing and implementing a user-unfriendly opt-in solution, now obsoleted by the ICO’s last-minute change of heart.
The other is from another friend of mine who is a lawyer, also working in the Internet sphere. He however disagreed with me (which isn’t terribly surprising, noone agrees with all their friends all the time, after all). He did so at some length, which I sha’n’t quote here verbatim and completely, as the comment was on a non-public Facebook post.
But Francis’s comment prompted me finally to get round to blogging about my thoughts on the EU “Cookie Directive”, why I think it’s such a terrible piece of legislation and why I believe the ICO handled the situation shamefully incompetently. Apart from anything else, I am currently standing for election to the Board of the Open Rights Group and it seems only fair to justify my opinion to the ORG members who will be considering whether or not they would like to vote for me as someone to represent them on ORG’s Board of Directors. And let me be clear here, I’m not falling out with Francis, I’m not wanting to provoke an argument and I’m not wanting to suggest that he’s foolish, naïve or anything else. I just disagree with his analysis of the situation.
I’m trying to access an XML-RPC service from C# that I’m building. I’ve had absolutely no response from my message on the XML-RPC.net YahooGroup, so I started looking at the only other .Net XML-RPC class library out there: XmlRpcCS, which is only confusing me further.
The cause of my problems appears to be that XML-RPC.Net seems to require all its proxy objects to be structs. I, however, would like to use class objects, so I can add other functionality into the classes (constructors, the ability to have properties that are masked from the XML-RPC output and so on).
Now if this were XML serialisation, I would use the attributes that control XML serialisation, such as
[XmlIgnore]. Without rewriting half of the class library, though (which would seem to defeat the purpose of using it!), I can’t do something like that.
Does anyone here have any experience of using an XML-RPC library for .Net?
(Cross-posted to csharp and ms_dot_net.)
For reasons too dull to explain, I’m trying to use regular expressions to postprocess an HTML-stream. I want to find all anchor (
<a/>) tags that link within our site, in this case using the domain name.
My regular expression looks right to me, but .Net is convinced I don’t have enough close-parentheses. I’ve added line breaks for clarity:
I’ve tested both the above code with the line breaks removed and the original code (which is compiled with RegexOptions.IgnorePatternWhitespace and has embedded comments for ease of maintenance. Each time, I get a System.ArgumentException:
parsing "..." - Not enough )'s.
Despite that I’m quite certain they’re perfectly matched.
Cross-posted to ms_dot_net and regexp.
Why is it that Microsoft appear to be completely incapable of writing decent code and documenting it?
I’m trying to work with SharePoint 2007 for a project at work. The developer textbooks haven’t yet been published (and the release dates have recently been pushed back), so all I have to rely on is the MSDN Library’s documentation of the API.
So when I see method descriptions like this (BaseFieldControl.RegisterFieldControl, fuck only knows what it does), I get pretty pissed off.
So I gave some feedback:
This is a public API, that developers need to access to work with SharePoint. Why on earth is there absolutely no documentation on some of these properties and methods?
Ridiculously poor; if one of my developers passed it to me for QA, I would have failed it and sent them to go do it all again, whilst hanging their head in shame.
I wonder if anyone will actually ever read it.
They want an arm and a leg from their developers!