Monthly Archives: September 2015

My coding role models

There were some interesting tweets the other day about programming role models when we were kids, or, more specifically the lack of them. The generation I’m talking about grew up with the BBC Micro, a computer that I credit for getting me where I am now. Growing up in the Middle East meant limited television and playing inside during the hottest parts of the day. Imagination and playing with friends staved off boredom, as did a fair few hours playing computer games.

I’ll be honest here, mostly I’d go round my friends house to play computer games. He had a Commodore 64 a much better games. Of the games I had for my BBC only Repton 2 and Elite were really any good.

Elite was, in some respects, the best game ever written. This may not be immediately obvious if you look at it in a modern context. The graphics are clunky, the sound is lo-fi and the game relied heavily on your imagination. Look at it in the context of what computers could do in those days and it was a technical tour de force.

As a young kid I was able to fly, trade and fight my way across thousands of planets spanning 8 galaxies. I could upgrade my ship and compete in what felt like a living, breathing universe. This was not a game on rails, this was a sandbox you could explore. Yes, you had to bring your own imagination, but as a kid of 10 I had that in bucketloads.

The fact that Braben and Bell were able to make my lowly BBC simulate all that was astounding for me. I wanted to know how. I was inspired to explore, and learn. And through that exploration I taught myself to program. It means that as the current incarnation of Elite pushes technical boundaries once again, I have a good appreciation of how it’s been done. I can also contribute to the community in the form of joystick maps and video tutorials. The very fact I could afford the gaming rig I use to play Elite: Dangerous is directly related to learning to program and taking the career path I did.

So I would argue there were programming role models when I was a kid. David and Ian, I salute you.

Why tech needs context

6am, and an alarm goes off on my phone. It’s time to get up for work. A discreet tap on my wrist at 7am from my watch alerts me to the fact it’s bin day. Today it’s garden waste, so the brown bin. 7:10, Another alarm on my watch: 5 minutes before I need to leave. Time to get my bag and put on my shoes.

I’m forgetful. I get caught up in things. And there is stuff that I really need to do at certain times. Like leave to catch trains. Or put the bins out. Mundane stuff, but important nonetheless.

But these things are contextual. And other than limited control over time and date I can’t really add context to them. I have 6 alarms relating to work which I can only limit to weekdays. I’d like to further limit them by special events (so only go off on weekdays that are not public holidays, and where I am not on holiday or otherwise out of the office). I’d also like to make them smart when it comes to location; “You are not at home, should I adjust your morning alarm?”

This leads to being able to schedule alarms to go off only if an event has occurred. Remind me to take out the brown bin every other week at 7am on a Monday, but only if I have put something in it since it was last put out. When I’ve done some gardening, “Hey, Siri! I’ve put some stuff in he brown bin”, and I know that I’ll get a reminder to put the bin out at the correct time.

Conceptually these are all easy things to do when considered in isolation, but become much harder when you start considering how it would work in the real world for all the different combinations people would want. Just knowing if it’s a public holiday can be confusing enough for me since my calendars insist on showing ones that are observed in Scotland but not England. Any system making informed decisions off this data would need to know about regional nuances like that. And that’s one of the simpler problems.

Smart reminders are coming though. I can envisage a time when I can just say “Hey, Siri! Remind me I need to buy some more tea for the office tomorrow,” and for it to know to remind me as I pull into the station that I need to deviate to a shop, plus tell me which is closest to my usual route. Then, knowing I paid using the company card, Siri will them prompt me when I get to the office to scan the receipt for my expenses.

We’re tantalisingly close, and I can’t wait until it starts becoming mainstream. In the mean time I’m just glad I managed to wake up on time the first day back after my holiday – I forgot to turn all my alarms back on, which could have been problematic.

Clumsy is the new [FR]agile

I recently gave a quick talk at Agile on the Bench in Norwich entitled ’Clumsy is the new [FR]agile’. The following is a rough transcript of that talk:

Hi, I’m Dom Davis, CTO at Rainbird, and lapsed Agile Evangelist.

I’m going to be honest here. When Paul asked me about coming to Agile On The Bench I fully expected to be sitting in the audience watching someone else talking. You see, I’ve rather fallen out with agile. I don’t recognise what people call Agile these days. I couldn’t even tell you what Agile is anymore.

In my last role I was confidently informed that I didn’t do agile because I didn’t do scrum – which was an interesting statement. Agile isn’t scrum. And Scrum spelled with a capital “Waterfall” isn’t agile either. It may sound harsh, but I can guarantee you that’s what they were practicing.

Part of this persons philosophy was that stand-ups were important, but hard to organise every day. So instead of five short daily stand-ups there was one hour long weekly standup. That’s not a stand-up. That’s an uncomfortable team meeting.

And it’s not just that one person. I’d go so far as to say that most people using Scrum aren’t really being Agile. At best they’re being Clumsy. At worst they’re deluding themselves. The same holds for Kanban, Lean and pretty much any flavour of Agile you care to mention.

The problem is that you cannot prescribe a one size fits all approach to software development. People are different. Teams are different. Companies are different. Trying to force people to work in a specific way simply because it has been prescribed as “Agile” is agile with a capital FR.

What works at company X may not work at company Y. And while it may look all fine and dandy at company X I’m willing to bet they also have issues – they’ve just got an evangelist who’s willing to stand up and talk about the good bits, while glossing over the problems.

This carbon copy approach shows a fundamental misunderstanding of what it means to be agile. Scrum, Kanban, Lean; these are all frameworks, philosophies you can weave into the very fabric of your company, not rigid processes to be mandated and enforced. Constraint and agility are diametrically opposed. One cannot allow the other. A rigid process, by definition, cannot be Agile.

And yet the virtues of Agile have been sung from the highest parapets. So much so that we all now know, at a visceral level, that Agile Is The Way. So if it doesn’t work for some reason we’ll just try another flavour of it. We’ll employ certified scrum masters and hope that if we believe hard enough, and follow the plan rigidly enough, it will all be OK.

It won’t, because you’re addressing the wrong problem. This is not the Agile way. It’s the Clumsy way. It’s only when you need to react fast, to be truly Agile, that you find out you’re actually Clumsy. And you find out the hard way, tripping over your processes and getting tied in knots.

Agile is not a process, it’s a state of being. It means you can act with agility. That you can react to the needs of the business, and to the pitfalls of software development in a timely manner. And that’s it. Everything else is process.

Most truly agile teams will review and change their process regularly: keep what is working at this time, shed what is not. What works today may not work in 6 months because the problem space is dynamic, constantly shifting. They understand this and embrace it. There is no perfect solution, just something that works well enough for now.

Strip away the buzzwords and we’re just talking about project management. Except project management is a dirty word. It’s enterprise-y, and we’re all ninja-rockstar-full-stack developers deploying fleets of containerised micro-services to the cloud. We don’t want to be constrained by Process.

But we do need something. It doesn’t need to be Process with a capital P, but simply building a Kanban board, running daily stand-ups, and declaring ourselves to be “agile” isn’t going to work. There are some fundamentals we need to get right. Without those fundamentals you’re setting yourself up to fail.

There are no quick wins. But there is basic starting point to get to the solutions that works for you, in your team, in your company. In the end it all boils down to communication. How do we communicate the requirements from our stakeholders and users to the development team? How do we communicate progress back to the stakeholders and users?

This could be anything from Post-It notes on a whiteboard and informal meetings when required, all the way up to full blown project management systems. Informal doesn’t scale well, and the more formalised the system the less agility it has, so there is a trade off.

But don’t start with the tools, or the process. Start with what you want to communicate. How do new issues enter the pipeline? How do we make sure that what is developed is what is required? How do we feedback progress?

Get that sorted and you’re well on the way to winning, regardless of how it’s done, or what you call it.

If you’re interested I use a process loosely based on Xanpan at Rainbird. I call this process ’Fred’, purely because people keep asking me what I use and I needed to give it a name. Fred, as practiced now, has little resemblance to Fred when I first called it that. It’s not without its issues.

If you want to hear more I’ll be ranting about Agile and Agile Processes in a longer session called ’Agile Smagile’ at NorDevCon.