Hi. I’m Max Woolf .

Here are some thoughts of mine.

Comments
agile agility scrum

Moving from Agile Development to agile development

What am I talking about? I’m talking about getting rid of ‘Agile Development’; certifications, rigid process, faux-flat company hierarchy and moving to agile development: near real-time communication, small feedback loops and empowerment of developers who are making software.

But I bet you’re wondering:

Why the sudden epiphany Max? Aren’t you a big advocate of Scrum?

Yeah, I was and still am to a certain extent, but I’ve recently started a new job in a much smaller team and it’s given me some perspective.

Scrum is good; great even. It still has a place amongst teams with little experience in developing software with agility. But it’s not, and should not be the be all and end all of software development. It certainly isn’t something that we should, as developers, aspire to as a long-term goal. It’s a stepping stone to a better way of working and a very worthwhile one too. It’s ‘agile with training wheels’. It quickly ingrains the principals of agile development in to its members. But we do not use training wheels forever and we definitely don’t hand out certificates and praise to those who encourage it. It starts to hold you back. We’ve reached a bizarre paradox at this point. You want to go faster (be more agile), but you just can’t because the rigid process (the stabilisers) is holding you back. You’re ready to move on but you can’t. The process is ingrained and beyond change.

As a result of this idea, why do we need ScrumMaster certifications or even the whole concept of a ScrumMaster. Not just because the name makes me cringe but because why do we want to encourage keeping the stabilisers attached? A true leader (or master if you insist) keeps the stabilisers attached for as little time as possible, empowering the people doing the work to do the best job they can and then slowly removes the stabilisers, encouraging the team to make mistakes and learn for themselves. The development team are probably smart people, you hired them after all. A bad leader says “It’s 11am. Time for a daily stand up because that’s what we always do.”

Convinced that Scrum might actually be holding you back? Ok, good. I’m not a believer in trashing a decent concept unless there’s a better one waiting to take its place. Like I said, that’s small-a, agile development. To be a member of an agile development team you don’t need a certificate, or even a fancy job title, you can be a manager if you want, team fascilitator, team leader, god of process, I don’t care. Just make sure you do the following:

Communicate

All the time. Ask questions. Make sure everyone knows what everyone else is doing. Use a daily stand-up if you want. Or don’t. Whatever works for your team.

Feedback to your customer atleast daily

Two, three, four, five times daily. They’re paying you to make something great but they run their business, they know what’s best. They must know what you’re doing so show them! Feedback can take many forms whether it be just a phone call to update them or a piece of shippable code so they can see a feature in progress. Whatever works for your team.

Spot issues early and resolve them quickly

Use sprint retrospectives if you want but in my experience, once every two weeks isn’t often enough. Problems come up unexpectedly, that’s why they’re called problems. Got an issue with management? Talk to management. Got an issue with code quality? Talk to the developers. Got an issue with the client? Talk to the client.

What I’ve described here is just a practical implementation of the Agile Manifesto, which is exactly what Scrum is but with less rigidity. My issue isn’t with Scrum itself, but with its inability to change without no longer being ‘Scrum’.

The rest is up to your team. They’re smart people. Empower them and they will, almost always, surprise you.

Comments
code language welsh

ProTip: Force use of another localisation in development (Objective-C)

I’m currently working on a bilingual Welsh/English app and while I was really happy to hear that iOS 8 will treat Welsh as a first class language, currently it does not. Making a Welsh localisation work is a pain.

I came across this handy fix to force the current build to load a Welsh localization. Assuming that you have Welsh set up as a localisation in XCode, you can force the device to think that Welsh is the first choice language and read in those strings instead of the default (in my case, English). This means when presenting to clients, I can ask the app to load in Welsh or English by changing a line of code and then submit the two apps separately to the app store.

In main.m before return [UIApplicationMain ...] just stick in these lines:

1
2
3

NSArray *langOrder = [NSArray arrayWithObjects:@"cy", nil];
[[NSUserDefaults standardUserDefaults] setObject:langOrder forKey:@"AppleLanguages"];
[[NSUserDefaults standardUserDefaults] synchronize];

Job done. Replase cy with en or any other language you have set up and you can force loading a particular language in development.

Comments
books code

The graduate software developers’ reading list

I started my first proper software development job at nearly 2 years ago now and I have done one thing more than anything else:

READ.

I’ve read books on development, code, business, agile, psychology and just being a better person. Some of the books were useless. Some were excellent and some I wish I had read while I was at university. Here’s a list of the books I’ve read in the last 2 years on relevant subjects with a few words on the ones that stood out.

Deal With It: Attitude for Coders – Written by Gavin Davies (@gavd_uk), this book is a must-read for any developer, new or old. It’s made up of lots of single page ideas, each one backed up by personal experience that makes it super-readable and really fun to read.

Ruby on Rails Tutorial – This is the tutorial for all new Rails developers.

I’ll be adding to this list over the next few days. Let me know which books you’ve found most useful in the comments.

Comments
compulsions obsessions ocd

The programmer who couldn’t stop

This post isn’t techy, but talks about an issue that affects many software developers.

Until very recently I suffered from obsessive-compulsive disorder. I use the word suffer because while I still feel the effects of OCD every day, I no longer feel a sense of suffering. I have read a lot of books on the subject of OCD and mental health, it is a fascinating topic but I finally found a book that I haven’t been able to put down. “The man who couldn’t stop: OCD and the true story of a life lost in thought” is, without doubt, the best book on the subject I have ever read and anybody with even a slight interest in OCD and mental health should read this book right now.

The book makes a clear differentiation between being diagnosed with OCD and being ‘a bit OCD’. A term that has appeared all too often in popular culture. “Sorry, I have to move that there. I’m a bit OCD.” is a stark contrast to the all-consuming fear of the feeling of guilt I would have because I didn’t check if I had unplugged my alarm clock. Because if I didn’t, it would catch fire and kill all of my family. Obviously. Let me give you a window in to that world.

Packed, ready to go. Turn off lights, shut doors, etc. Oh wait, did I turn off the alarm clock? I’d better go and check. Yeah, it’s off. I may as well turn the light off, I don’t want to waste electricity. Did I turn it off properly? I better turn it on and off again, in case the switch didn’t click properly. Oh, I’ll just unplug it to make sure. Is it touching that other plug? I had better make sure they’re not touching each other. Ok, that’s fine now. I’ll leave. Leave the house, lock the door, walk down the road and the feeling of anxiety hits again. I spent all that time worrying about the alarm clock but I’m sure I left the hob on. I couldn’t possibly go home to check it? Well, I’d rather be late for work than burn down my home. I’ll walk back and check. Walk home. Open the door. Check the hob. Tap each hob dial chanting “Off”, “Off”, “Off”, “Off” for each one. And again. And once more. Ok ready… no wait, one more, “Off”, “Off”, “Off”, “Off”. While I’m here, I’m going to check the alarm clock again. Ok, time to go to work. Lock the door. Walk to work. Get to work. Did I leave the door unlocked?

I’m lucky. While OCD symptoms used to run my life. They rarely do anymore. Anybody who’s ever described themselves as ‘a bit OCD’ should read the book. When they’re finished, I hope they prefer to use the term ‘quirky’ from now on.

Comments
agile

Why agile? It works. I think.

I recently discovered that ‘agile’ (small A, big a, I don’t care.) is more than just another bullet in your sales guy’s buzzword bullshit bingo armoury. I always had my suspicions that there was something good there, now I’ve had a go and I get it. So here’s a few things that I have learned. (If you’re already doing this, none of this will be new to you but I wanted to get them written down.)

You don’t do agile.

Without sounding like the aformentioned sales guy, you can’t do agile. You can be agile. Duh.

In other words, you can’t follow a strict regiment of pre-planned rules and be agile. Obviously. You can, however, quickly react to change. Identify issues and solve them before they become a big problem.

Scrum is a set of pre-planned rules that facilitate being more agile. But it’s not the be all and end all. Your team will probably outgrow Scrum as they find what makes them more productive. I’ve heard it described as “agile with training wheels”. I agree.

People are really bad at estimating

Utterly, utterly awful. Story points are by no means a silver bullet, but they’re better than estimating in hours. Try out different relative estimation techniques such as affinity estimation or planning poker.

Protip: Don’t give up. It’s hard. As my next point explains…

Being agile is difficult

To properly implement Scrum (which is not the only way of being agile, but it’s a good start), you may have to do things you’d be otherwise uncomfortable with in any other social situation.

  • Aggressively timeboxing meetings can make a Scrum Master look rude but can greatly improve the efficiency of meetings.
  • Explaining to a client that interrupting a sprint for a ‘critical’ (not really critical) task can have repercussions for productivity. (Programmers are not units of work.)
  • (Developers) Being empowered to get on and do your job.
  • (Managers) Trusting your developers to do their job.
  • Being ‘that guy’ who says “this isn’t going to work, we should stop.”
  • Not planning months/years in advance. You may feel better, but that won’t matter when you overshoot your deadline by 6 months. Also, your client will be annoyed when you spent all that time estimating and you were wrong anyway!

These are all things that traditional common sense say are bad. Rudeness, managers not managing, admitting defeat early on, not planning well. You shouldn’t do these things! Except that actually they’re fine.

  • Rudeness isn’t as rude when its for the good of a development team. Even if you feel uncomfortable at the time.
  • Telling clients how things are done may seem like biting the hand that feeds you. But setting expectations is equally as important.
  • Developers are smart. They don’t need to be babysat.
  • Managers are natural risk-mitigators. But there is a clear dividing line between manager and Scrum Master.
  • Being ‘that guy’ can save your company months of wasted effort and money.
  • Planning in short bursts promotes focus and accepts the fact that estimates more than 2 weeks(?) in the future are essentially useless.

Being agile is fun

When your team is settled in to the agile flow, it becomes fun quickly.

Gone are the semi-awkward “I don’t think we should talk about that here” moments in the daily stand-up. It becomes a game as to which team can get their stand-up finished most efficiently.

Gone are the awkward messages from clients explaining that they want that feature right now.

Gone are micromanagers and in come Scrum Masters looking out for their development teams.

Gone are ‘code-monkey’ developers who wait patiently for orders before dutifully producing code in a caffeine-fuelled stupor.

Gone are the 2 year development cycles that inevitably end in failure.

But it’s hard.

Yeah. Nothing I can do about that. You’ll have to decide if its worth it for you. These are based on my experiences and they are by no means representative of the rest of developer-kind.

Comments
agile

In praise of getting shit done.

I’ve learnt a lot about myself in the last 18 months, both personally and professionally. This post is just about one of those things: I’m impatient.

Got a good idea? Go and do it. Please, please, please don’t create a focus group, send our a survey, sit on the idea for 6 weeks, get a load of opinions, create a solid business plan, find a market fit or any of that shit. JUST DO IT! But be prepared to fail. (It’s allowed).

That stuff is important. But not yet. Currently all you have is yourself, an idea and an early retirement plan if it all goes well. It’s worth nothing. So stop thinking outside the box, formulating a plan, conceptualising, projecting and even planning.

Just go and get some shit done.

Comments
coding education nhshd

Age is largely irrelevant.

I’ve lost count how many times over the last 12 months that I’ve been told how it’s done by people younger than me.

I’m 22. So not old by any stretch of the imagination. I met a young lady (@thisisneena) at the NHS Hack Weekend in Cardiff last week. Members of the NHS come with problems they want solving and coders solve them. She came with her father (a surgeon), an idea, a strong vision and an early-stage prototype she’d coded herself. She didn’t worry herself about how it could be commercialised, whether someone was going to steal her idea or even the concept of a minimum viable product.

She did the four things that stand between an idea and execution:

  1. She found something she was interested in.
  2. Found a problem.
  3. Learnt the skills needed to fix it.
  4. Just got on and solved the problem! Her end goal was not to make a bucket of money or tie the NHS in to some contract that meant she could retire at 17 on a beach somewhere. The end goal was to make people’s lives better.

Me, @thisisneena and her father presenting ClEWS at #nhshd

With age brings experience, but don’t let that overshadow all of the things that youth brings to the table. Excitement, enthusiasm, naivity (yes, it’s a good thing in moderation), positivity and the overriding feeling of coding because it’s fun! With age also comes cynicism, the need to provide for ones family and to pay the bills. That’s not neccessarily a bad thing (those who know me will attest to my overflowing levels of cynicism for one so young.) but we mustn’t forget the long nights spent coding because our ICT teacher didn’t know enough to teach us anything at school or the first time we put a website on geocities for the world to see and the excitement that brought us. (Unless it was just me?)

Remember, these kids are smart. Really smart. If you see a young coder who’s learning, offer them work experience, offer to teach them a skill or invite them to a tech meetup. Just get them involved. They’ll thank you for it.

(Picture credits: @paul_clarke)

Comments
coding education learning

Things I did not learn during my degree vs Things I did learn during my degree

Having only graduated in July 2012, my degree is still relatively fresh in my head. I studied Music Informatics at the University of Sussex. Though it turned out to be basically a Computer Science degree with a slight musical slant since it turned out I was better at coding than playing the piano. I’m now a full-time software developer and I truly enjoy what I do, however, many (if not the majority) of the skills I use day-to-day were not directly taught to me during my degree. Here’s a list of the things I use day to day that I did not learn as a direct result of my studies.

Did not learn

  • Version control using Git.
  • Test-driven development.
  • Testing at all, except for 30 minutes on how to use JUnit.
  • Any sort of full-stack web framework. (Rails, Django, etc.)
  • Collaborative working using Git and GitHub (or similar).
  • Deployment strategies.
  • Any sort of server administration.
  • Use of a tool such as Redmine or JIRA.
  • Anything to do with Agile. (Scrum, Kanban, etc.)

Let’s contrast that with a list of the things I did learn.

Did learn

  • XSLT, DTDs, AJAX (not using jQuery)
  • MATLAB
  • Java
  • Subversion
  • Waterfall methods
  • OpenCV
  • Machine Learning

See where I’m going with this? Yeah, there’s a couple of cool things on that list. Computer vision is awesome, but I learnt so few of the tools and techniques I use day-to-day. Knowing Git, TDD and being familar with some sort of Agile methodology is pretty much assumed these days, but in three years and after £10,000, I did not know them.

I took a module in my final year called ‘Web Computing’. I expected to learn about web frameworks, web apps, stuff that would be useful if I wanted to go in to a career in what I would describe as web computing. First lecture:

Be aware that this course does not cover PHP, Rails, or anything like that…

I remember that quote. “…or anything like that”, like full-stack frameworks were somehow a waste of time. That module covered XSLT, DTDs, XML, that sort of thing. I learnt very little in that course other than the fact that I did not enjoy it. If an API provides XML instead of JSON I shudder now. But JSON was not even mentioned. Just to remind you, this module was taken in 2011/2012. This is not a long time ago. Seems to me that if Universities are tasked with preparing students with the skills required of them by industry, in my experience, the university failed.

I don’t mean to be totally negative about my university experience. I enjoyed myself, made some friends, discovered some hobbies and I’d do it all again. But in terms of my university experience preparing me for the workplace, I remain to be convinced that my student loan was worth it.

Comments
code education learning

Can adults learn to code?

tl,dr Yes.

Since becoming more involved with getting kids in to coding recently, I’ve heard the phrase “Year 8 is too late!” quite a lot and before this week, I would’ve agreed, mostly. It’s harder to learn new skills when you’re older, it’s a well-known fact. There’s a theory of ‘brain plasticity’ which suggests that children’s brains are much more able to learn new things than adults. Who am I to argue with scientists? But what I experienced earlier this week was truly remarkable.

First, some context…

I was asked by Cyfle (pronounced ‘cuh-fluh’, not ‘siffle’ as I embarassingly found out) to run a 2 day course called ‘Building an iOS App from Start to Finish’. The course would be open to the general public and participants would have zero programming knowledge, although they all knew that they would be learning to code. So although they had no knowledge, they were all willing and eager to learn! (It’s also worth noting that over half of the participants were bilingual.)

I’ll admit to being skeptical. If you’re teaching adults with zero programming ability to write an iOS application, chances are you’re thinking you might teach some simple HTML/JS framework which produces something that looks a bit like a native app. The honest truth is that my javascript skills SUCK. Big time. I can get by, but there’s no way I’m in any position to teach anyone anything. At this point, I have two choices.

  1. I can turn down the work. I don’t want to do this.
  2. Teach complete programming novices how to code in Objective-C.

Oh hell no.

Teach complete novices to code in Objective-C?! Seriously? I must be mad. So I gave it some thought. Before I got started, or even accepted the work, I had to decide if it was even possible to make this a success. The big questions that needed answering were:

  1. Why do experienced developers shy away from learning Objective-C? Are they things that we can overcome?
  2. Am I going to look like an idiot?

So, question 1.

Why do experienced developers shy away from learning Objective-C?

Well that’s quite simple really…

It’s hard!

I can’t overstate that enough. That said, I have to think about why it’s so hard. What makes it hard? I think a great majority of it’s perceived difficulty is due to how syntacticly unfamilar it is to experienced developers despite being a very idiomatic object-orientated programming language. This isn’t something that complete novices will have to compete with. This will be their only exposure to programming in their lives so far. They don’t know languages that you and me might consider ‘easier’ such as Ruby or Python even exist. I think we can overcome this.

Am I going to look like an idiot?

Maybe. Maybe not.

But there’s only one way to find out…

In case you hadn’t figured it out yet, I agreed to run the course. It would be an interesting experience whatever the outcome.

Day 1

Having arrived and met my participants, I quickly set to find out about them. I had 8 adults between the ages of 30-55(ish) (and all older than me, yes), none of whom had ever coded before but all were comfortably computer literate. They all worked for companies and charities who are looking to build an app or find out whether or not an app is right for them and they all wanted to have a taster of the programming side of things. Great! I had planned for exactly what I got, so no complaints so far.

We jumped head first in to some classic OO programming concepts. Classes, objects, instance variables… the usual stuff. I figured this would be a good place to start. We had a break and then I fired out the question:

What is an object?

Which was followed almost instantly by the response:

An instance of a class.

This had to be a good sign. I felt like this dude.

OH HELLS YES

I had 8 people who were confident with the theory behind (admittedly, the basics) of object-orientated programming. Next, we started to code. The command-line application template in XCode 4.2 was excellent. We could write some simple statements and get the computer outputting stuff to the screen. We started with the basics:

1

NSLog(@"Hello, world!");

Oh, wow. We just told the computer to do something, and it did it. No big deal. Except that it was. This was the first successful program that these people had written. So what’s next? Do it three times.

1
2
3

NSLog(@"Hello, world!");
NSLog(@"Hello, world!");
NSLog(@"Hello, world!");

Next? Refactor in to a variable:

1
2
3
4

NSString *message = @"Hello, world!";
NSLog(message);
NSLog(message);
NSLog(message);

We carried on like this for the rest of the day. Tiny, tiny, iterations of our program. Which slowly got steadily more and more complex. By the end of the day they had all produced something like this.

1
2
3
4
5
6

int number = 3;

if (number >= 0 && number <= 10 && number * number == 9)
{
    NSLog(@"Congratulations, you found the correct number.");
}

and other examples that made use of for loops, NSDictionary and NSArray. Even better, we even got time to discuss mutability and how it works in this context.

At this point, I’m pretty stoked.

These guys are really getting it. Let’s make an app. It won’t be a difficult, but just a small app that increases a number on the screen if you press one button, and decreases if you press another. We set up our XCode project, I showed them how to code one button and asked if they could get on and code the other. The majority of them did with very little input. The ones that did struggle were with syntactic issues and not a failure in understanding the underlying concepts. Syntactic fluency in programming comes with practice. So I’m not too worried about that.

As time passed the participants went from strength to strength with 6 of the 8 people who started the course completing it with a fully working calculator application. I may not have scientifically disproved that “year 8 is too late”, but it’s certainly not as much as a certainty as we had assumed. From now on, when I hear people say “I’m too old to learn to code.” I’ll be more willing to argue with them.

Comments
coding education

Those who can’t do…

This is an old blog post I started writing about a month ago but never got a chance to finish it. I’m not sure I agree with everything I’ve said in it but will post it here and hopefully build on it at a later date.

Those who can’t do, teach. Those who can’t teach, teach P.E.

Not that I ever agreed with this statement (the first half of it anyway; I had some pretty dire P.E. teachers), but when put in the context of programming, never has a more untrue phrase been uttered. When I refer to programming in this post, I’m talking about the process of solving a problem by writing code, not software development in its wider context.

My previous two posts have been comments/rants on the state of education and some school’s totally inability to teach children how to program. This post seeks to actually provide some constructive ideas on what could be done about it by looking at how programming can be ‘taught’. Ask any Computer Science undergraduate “How did you get in to programming?”, and I guarantee that a tiny, tiny, minority will say “I learnt x language at school”. Those that do say that, will even more rarely have come from a comprehensive school background.

It’s all very well to say we’re going to address this, but ‘coding’ isn’t one skill that can be taught. It’s a combination of skills ranging from critical thinking, problem solving and sometimes just a bit of dumb luck. Let’s assume that we have a class of children, all of whom are fairly bright and posess good problem solving skills and all have an active interest in learning to code. I realise this is a massive assumption, but you have to start somewhere, right? What next?

Starting from nothing, it’s often very tempting to dive in to ‘scripting’. In other words, writing a set of commands in any language, executed one after another to achieve a task, like this:

1
2
3
4

x = 10
x + 100
output x
=> 110

Do line 1, line 2, line 3, get line 4…. etc. This is the easiest type of coding to teach and the easiest to learn, despite this type of code being used almost never in practice. Unless you’re an über-hipster writing all your code in some snazzy functional languauge, the majority of code these days is written in Object-Orientated Languages (OO) such as Java, Ruby, Objective-C and sometimes PHP. I spent a lot of time at university discussing the pros and cons of teaching OOP to university-age students first instead of teaching them to script first and we largely agreed that using an ‘objects first’ approach was generally a good thing, especially for the 18+ age group. Although this conclusion wasn’t reached by all people in this group. I however, saw no reason why this should not be extended to younger kids. Explain coding to them as a way of expressing ‘things’ as code, and you might be on to something.

Explain that we can create templates, take a car for example. All cars have a set of attributes, these attributes are the same, but their values are often different. Cars can also all do the same set of things: open the boot, get spray painted, go forward, but how they do it depends on their individual attributes.

A Car in pseudocode
1
2
3
4
5
6
7
8
9
10

class Car
    var make
    var model
    var colour
    var no_of_doors

    function paint(new_colour)
        colour = new_colour
    end
end
Using a Car in pseudocode
1
2
3
4
5
6
7
8

car = new Car
car.make = 'Nissan'
car.model = 'Note'
car.colour = 'Blue'
car.no_of_doors = 5
car.paint('Orange')
car.colour
=> 'Orange'

This may all seem very obvious, but to someone just learning how to program, this is a totally different thought process than the first example of ‘scripting’. You cannot expect someone who has grasped the ideas in the first example to automatically be able to understand the ideas presented in the second and third. However, those are the skills that are really used day-to-day by most programmers. So why would we teach kids anything else?