Agile papercuts

Nine of diamonds in the rough

I’ve worked on a few projects and I’ve tried many ways to run them. The agile manifesto is a great starting point, and should be in your bookmarks for quick reference. But when you put it into practice, your first thought is the mistakes you made last time, the lessons you learned, so you can do better this time.

So you look at where things failed, and you add a process around it, maybe one of your own, making taking inspiration from others.

For example, you had a big problem with release management in your last project, and git flow is a process for release management, so you try it on for size.

But the planning decisions about when to deliver features, and how the support and feature releases work together are not changed, because it was a release management problem, not a planning problem. So you add more process.


Let’s assume you don’t have time for root cause analysis of everything that caused you pain last time. Just assume everything is causing some pain, but for some things the benefit outweighs the cost.

How do you spot what causes more pain than benefit?

Does your process support the people, or sideline them? Is the documentation useful or mothballed as soon as it is delivered? In other words, are you valuing the things on the right more than the things on the left?

As developers, it is a long battle to get over your ego, and the sunk code fallacy, and learn not to be precious about the code you’ve written because the product you’re delivering can always be improved, and if your code is no longer fit for that product, it should be removed. Celebrate the code you no longer have to maintain.

As tech leads, we can be just as precious of our procedures and our practices, but they can be even more painful that the code. They’re harder to refactor, to measure, to test, because people are less predictable than code, but we need to be willing to identify waste, and identify the pain points so that we can address them, and remove practices if necessary. Measure where you can, but don’t be afraid to be as ruthless with your process as you are with your code. Anything that didn’t add value is weighing you down, and even those small papercuts that sung every time are worth removing.

Whatever you think Agile Is, even if you think Agile Is Dead, don’t forget your process is as much a part of the delivery as the code you produce. Own it. Trim it.

Agile Is…'re a dinosaurIf you’re not agile…

For those of you who came to this blog for my rant on Agile Is Dead, I’d like to recommend these posts from Nathan Gloyn if you want something more actionable.

I can’t say my day job is all agile, but I try and nudge us down the continuum where I can. Process is all about supporting people, rather than vice versa, but documentation it’s one area that’s harder to go agile with. All my recent projects have a set of must have requirements defined as legislation by politicians in parliament, and it is often clear that implementation is not a primary concern. Legislation appears designed for ambiguity, with the expectation that courts or ministers will be able to clarify the grey areas. Which means more documentation.

Only one project I have worked on recently allowed us to have some influence on the legislation, because we were working directly with the government department involved, and the chief civil servants involved in the legislation were in our workshops, and the project started before the legislation was complete. It’s a strange, and not entirely unpleasant, feeling getting answers to outstanding questions from a politician reading amendments in parliament.

HTC One Mini vs One Mini 2

As a wee aside, and because my last post about an HTC phone was one of my most popular, I wanted to do a quick follow-up to my last post to talk about the phone.

I had an HTC One Mini that stopped responding. It was an ok phone but was often slow and occasionally crashed. When it finally died, within warranty, I sent it back to HTC for repair. I was told I’d get an update within 2 weeks, and on the 14th day after it arrived at the repair centre, I was told they had to send off for a new part.

2 weeks after that, I found out the new part was an HTC One Mini 2, which is one of the stupidest names for a phone I’ve come across. At least the Hero, Desire and Incredible made some kind of aspirational sense.

Having lived with this new phone for a few months now, I do prefer it to the previous phone, but I can’t recommend it.

It’s faster, runs cooler, and lasts longer than the phone it replaces, but the camera is very very bad. That was one thing the previous phone got very right : a responsive camera, that took reasonable pictures. This one is not an UltraPixel camera so the pictures are grainy, the shutter speed is only good for completely stationary objects, and the pictures take far longer to save than they ever did on any previous phone, even when they were saving to cheap sd cards.

More than that however, in fixing the crashes, the software updates have left the phone in a state where it constantly needs rebooted (often via the power+volume-up combo) as the lag time gets intolerable.

I’ve now had 4 HTC phones, and this one will definitely be my last. I’m not sure where to go next though. Maybe LG, maybe Motorola, possibly Sony.

Any recommendations?

Losing tokens : 2 factor authentication recovery

Use your palm to sign in
Use your palm to sign in

My phone broke. I lost access to Google Authenticate and the second half of my two factor authentication.

It was a great opportunity to look at how each of the main services deal with recovery. I’m always looking to increase the baseline of security in every new body of work, and 2-Factor authentication is one interesting avenue, but has a big potential failure scenario. I want to look at how the services deal with this to understand the trade offs.

For those of you unfamiliar with the concept, authentication is generally performed by one of 3 factors : something you know (e.g. a password), something you have (e.g. your car key) or something you are (e.g. fingerprints). 2 factor authentication asks you to prove your identity via 2 of these channels, rather than one, and often chooses the something you have and something you know channels because of the difficulty of replacing the something you are channel if the security is compromised.

Most of the services I discuss here use Google Authenticator which uses your phone as the something you have, seeded with a shared secret (usually encoded as a 2d barcode) to generate a new code at regular intervals that should appear random to any observer but always consistent between server and client.

Many of the services use one-time codes to allow you to log in if you lose your device, and some force you to enter one of those codes as part of the verification process. For all those that provide it, print out those codes as soon as you get the option, and keep their printout safe not near your phone.

The services

Google : provides a set of 10 one time codes. An email when any is used. Easy migration process to a new device, automatically disabling the old device.

Github : sends a text to my phone. Not so good for a stolen phone.

WordPress : a set of 10 one time codes, but no email indication, when one is used. Frustratingly I have to disable and re-enable 2FA to move to a new device, rather than WordPress disabling the old device automatically. Although it does have the nice side effect, unlike Google, of emailing me to let me know a new device was added.

Twitter : temporary password, with 1 hour expiry, provided you’re logged in on another device. For most services this should not be a problem, but it’s a good reminder to ensure you always have more than one trusted device for an account so you can create new trust relationships and disable old ones.

Dropbox : can re-enable authenticator via barcode, if logged in on another device. Email is sent.

I like the Google and WordPress approach for simplicity, if you’re organised enough to use paper as you’re backup device, but I’m comfortable with the approach taken by Dropbox and Twitter that use another device for the authentication.


I don’t like the Github approach, because it fails to recognise the use of the phone for multiple purposes, making a phone much more valuable a target. Luckily my phone was bricked, but I continue to monitor my accounts for suspicious activity, just in case it comes back to life now I’ve been sent a replacement.

I like notifications. I get email notifications on multiple devices and as they are timely, I know immediately if there are unexpected changes. Good marks for Google and WordPress here, but I wish Google sent emails for enabling on a new device and WordPress sent emails for use of one time codes.

I prefer the one time code approach for the way I like to work but I can see the benefits of the multiple trusted device approach. I can’t see any benefits to the github recovery approach apart from simplicity.

2 factor authentication is good, but check your recovery strategy now. I only got back into my accounts because I was prepared.

Further reading

★ : Two-Factor Authentication Hacked: Why You Shouldn’t Panic

Be sure you have a backup plan, for Apple and others. I almost lost access to some of my accounts because I misplaced my backup keys, similar to this guy.

If you lose your phone, or are scared you will, have a look at this Lifehacker guide before you enable 2-factor authentication on your accounts.

Is your CPU time there to be stolen?

Or can it be bartered? If you were given the choice between giving up cpu time, giving up privacy, or giving up money, to reimburse a developer for their time, which would you choose?

If you don’t feed us, do we not starve?

RT @ppinternational: uTorrent client is stealing your CPU cycles to mine #bitcoin

The Monty Hall problem

One of these things is not like the other

There’s a bit of a meme going about trying to explain The Monty Hall problem. It’s an interesting statistical problem because the result appears at first to be counterintuitive.

The basic formulation comes from a game show, where the final round consisted of three boxes, and behind 1 is a car, and the other 2 are goats.

If you pick the car, you keep it.

The complication in the setup comes from the host, Monty Hall, who, after you’ve picked a box, opens another box to reveal a goat, then gives you the opportunity to stick or swap. The question is, in a statistical calculation, should you switch?

The naive answer would suggest that as there’s only 2 boxes left, there’s a 50/50 chance that you’ve chosen the car. But that formulation misses the important facts that you choose a box first, and you are always shown a goat. There’s a lot of descriptions that show how the possibilities collapse with numerous branches to show that in 2/3rds of cases, it pays to switch.

There is a simpler way of thinking about the solution. In 2/3rds of cases, you choose a goat. Since Monty had to reveal a goat, changing your mind guarantees you a car in those cases. In the other 1/3rd, you picked the car in the first case.

Sometimes statistics is unintuitive because you have the wrong model, and users can’t see the wood for the decision trees. There are good reasons for some faulty models to exist, but these should be corrected and challenged.

Can’t patch, won’t patch

As a software developer, I take a keen interest in the platforms I am developing on, as that’s often the one thing I have least control over, given that the customer will ultimately be installing in their environment in most cases.

As a Windows developer with an Android phone, this story particularly interests me from a security perspective. I don’t want to have to target a moving platform, but equally I don’t want my software compromised by the security of the system it runs on, so having developed and supported projects under WIndows (mainly web via IIS, and IE on intranet) and Android, the recent spat between Microsoft and Google over security exploits and Google’s “Project Zero” has been of big interest to me.

Patching my thumb with gauze
Patching my thumb

The Microsoft bugs mentioned in the posts show how responsive a company needs to be to stay on top of security. For a product as big as Windows, 90 days is not much time to implement and test a fix. Microsoft obviously want to make their job as easy as they can to get those fixes out quickly, so they officially only support patches for users running up to date versions, including service packs. Their support for Windows expires if you haven’t updated for 2 years, and for most of their consumer software if you haven’t updated for 1 year. (note that Windows 8 is supported well past 2018, but only if you’ve been installing the free service packs).

Google’s problem with Android is that it has been open for OEMs to adapt for their platforms, at which point it is no longer Google’s Android. Whilst Google has worked to minimise the things that OEMs can control, including moving the WebView component at the heart of the flaw into Google Play in Android 4.4 and higher, the platform is still reliant on OEM support as much as, if not more than, Google. That is pretty much Google’s position, that the handset manufacturers need to update to a more recent platform, or submit a patch for Google to distribute to all the OEMs.

So if you’re stuck on Jelly Bean, you now have to either rely on the support commitment the manufacturer has to a handset that is no longer making them money, or use the open nature of the platform to install an alternative Android, not provided by the OEM.There are workarounds using other browsers, but they rely on users understanding what webview is (and potentially disabling WebView in all the apps, like Facebook, that use it).

Google seems to care deeply about server-side security and was seemed genuinely angry about the NSA breach between their data centres, but their record on the client side isn’t great. Android permissions, and Chrome passwords are two key examples. Microsoft’s “Scroogled” campaign attempted to cast to same doubt on Google’s cloud security, and was partially successful, although Microsoft’s successful certification of Azure to ISO-27018 is a far better card to play in this battle.

Google’s Project Zero is definitely a good way to set a rising tide of security, and is an essential part of the response we need to the Heartbleed and ShellShock exploits from last year, and the ongoing revelations about back-doors that spy agencies around the world have discovered. Google is not immune from the rising tide, and has fallen foul itself in meeting good practice. Microsoft seems to be their biggest critic in this area, but it’s been firing blanks, whilst open source vendors have been busy patching and moving on.

As a user, I know hackers are working to find exploits, so any exploitable discover has to be disclosed, to those who can fix it first, and to the rest of the community in a reasonable time, so that users can protect themselves. The problem with disclosure only comes where there is no possible means for the average user to defend themselves, which is precisely the problem with the above exploits. Usually, “Open Source” is given as the answer to empower users, but in this case, open source isn’t enough to get Android fixed. That’s still no reason to hide the exploit however, as users need to know if they need to protect themselves, especially if the solution is to avoid certain apps or websites.

Do you think Project Zero has demonstrated responsible disclosure?


Growth, together


agile, project management, fun at work

Speech and Science

Just another weblog

Rough Copy Media

media analysis / with added swearing

Simple Programmer

Making The Complex Simple

How To Tutorials

PHP, ASP, .Net, Linux, SEO


My eBooks are available at Amazon Worldwide

James Radcliffe, Musician. Music, Blog, Pictures, Live, News...

The Code Club Blog

Adventures in Teaching Kids How to Code

The Inner Donkey Sanctuary

Taking care of my inner donkey since 1977

Stack trace ramblings

Just another weblog

The DIEM Project

Dynamic Images and Eye Movements

Voidspace - Cyberpunk, Spirituality, & Python

Just another weblog

the HabitForge blog

Simple Accountability. Positive Change.

James Wiseman

Mainly programming, with a bit of science thrown in


on making software

Don Charisma

because anything is possible with Charisma

Kendall F. Person, thepublicblogger

where blogging is a performance art and every post is a show.


Get every new post delivered to your Inbox.

Join 1,565 other followers

%d bloggers like this: