anthony galvin

What does work sound like.

What should work sound like.

If you walked the floors of a successful, creative digital agency with your eyes closed could you tell if ‘things’ were getting done.

I noticed that @crashposition had a couple of playlists called “Music for coding and thinking” - which got me thinking about the way developers use music.

One of the 12 items on the Joel Test is a quiet working environment, without distractions. For many developers, what this means in practice is a quiet environment where they can put on some oversized headphones to filter out interruptions and side conversations - and create their own carefully controlled musical accompaniment to coding.

In most cases developers are trying to create or maintain ’flow’. Flow is for many coders the thing that gives them most satisfaction - the point where almost effortlessly working code seems to shoot from the brain through the keyboard and onto the screen without interruption. Coding downhill, with your feet off the pedals.

For many developers a day with good flow is a ‘good day at the office’.

Flow can be deceptive - extended periods of head down development without collaboration or an alternative viewpoint can result in a spaghetti code pile up of insane proportions. I’ve worked on plenty of projects where someone sat up all night writing code poetry  - 'fixing everything’ - because they were in the zone - only to leave the team saddled with the Object Oriented equivalent of doggrel.

Collaboration is a key attribute of a good developer, something that is especially true within an agency environment, but also true for anyone who isn’t just a 'lone wolf’ developer. Which means how effective is 'headphones on, head down coding’? Finding the right channel and balance of communication is important - traditionally IRC has provided the right level of persistence and real time for most developer discussion, but increasingly new tools such as HipChat and Campfire are finding ground. This seems to be especially true with more distributed remote teams.

So what to listen whilst coding, or rephrased, is there a musical shortcut to achieving ‘flow’. If it was that simple then I’d have one playlist or a couple of tunes to listen to on loop that would instantly transport me to the land of easy coding. If only it was that simple.

I’m sure you didn’t mean to create this problem. It probably seemed to make a lot of sense at the time. The client was a pain, you were under pressure to deliver - producer over your shoulder, asking “is it done yet”. As for that Tech Lead, he couldn’t code review his way out of a paper bag.

A project that nobody cared about. Ship it. Move on.

And it shows. Because 2 years later we are staring at the code. Trying to fix up some problem or other. It’s hard to know where to start because, well, there’s not many comments, the commit messages are garbage and the little documentation that there is makes no sense.

I understand that you didn’t think anyone would download that app, but people have. And the client, despite what you thought, thinks this is quite a good product and would like to promote it, if only it wasn’t so buggy. So now it’s over to us.

It’s OK for you, and the rest of the team. You left. A contractor. Got fired. Who knows, but you’re not here now as a couple of us go toe-to-toe with your lack of error handling and crazy re-invention of the most common design patterns.

And you know what, I know that we could all write better code, that I don’t have the context of those meetings and planning session when it all made sense. I wasn’t there.

But next time just write a few bloody comments and maybe some documentation that doesn’t assume you know the app inside out already. And think about those of us who have to up pick your pieces…

How sizing stories (points, t-shirt sizes, days & hours) is more than just Numberwang.

For (digital) agencies who use agile techniques for managing the design and development process there are some added complexities hidden in the abstractions of the story sizing.

Depending on the nature of the development project, a typical agency team might run the gamut of disciplines, from Interaction & Visual Designers, working in Illustrator and Photoshop through to Python engineers coding in Vim and living in the command line. And each with a (subtly) different understanding of the complexities involved.

Planning poker is the technique of getting multiple people on the team to independently size user stories, whilst trying to avoid the risks of ‘anchoring’. It’s a great method for driving cross discipline understanding of those tiny assumptions that can threaten to derail a project further down the line.

Which looks something like this:  Sat in a circle, post-it notes scattered across the floor and walls, someone is describing a level understanding of a particular user story — it’s pretty simple on the surface “As a user I can sign-in to the platform, so I can register to use the service”. People scribble on the post it notes, using the Fibonacci sequence to size stories based on the relative complexity involved for the UX (interaction and visual design) and technology teams. After a few seconds everyone stops writing and holds up their post-it notes. It’s near the start of the meeting so people are still getting a little warmed up, even so the variance in the numbers is quite high. Not just between disciplines but also between team members who work in the same area. This is where the interesting bit starts.

The discussion that follows is the bit I find fascinating. The cases where someone in tech misunderstands the complexity of a design challenge or someone missing the difficulty of integrating with a third-party (“it’s just an API call”) is understandable — that’s why we are doing this as a cross disciplinary group. These are easy to flush out and correct.

The real area of interest is where people explain the assumptions behind the scores they’ve given. At this point we are into the details, and it’s great for the momentum of the project. Weeks of thinking, sketching and notes come tumbling out in the conversation — no amount of ‘annotated wires’ can accomplish the benefit of someone challenging why “that’s only a 3".

Capturing these assumptions is key — they make up the real scope and difficulty of a story. Often it’s also the risk factor that you’re gathering “I gave it a 21 because we just don’t know exactly how that’s going to work”. Whilst all forms of planning and project management are probably inherently flawed, you’re unlikely to get this level of collaboration and discussion whilst scoping out a typical waterfall build.

Agencies running agile are usually working with more constraints than a development shop. The client will probably have a fixed budget and timeline, so the only area of flexibility is scope. Whilst the aims of the project are (hopefully) going to be clearly documented and contractually agreed, these small instances of scope and the relationship between a ‘must’ and ‘could’ are the area of flex that teams are going to need deal with the reality of ‘unpacking a story’ and finding it’s more of a nightmare than a fairy tale. But that’s probably something to add to the backlog for another post…