Andy Hawthorne

Project manager, writer and photographer

Coding Up a Storm - the agile way

I’ve led teams of developers through an eclectic mix of projects. Often in digital agencies where our external clients came from many different areas of business.

Managing projects in that context needs a method. So I looked for a working method that would help. Enter the agile manifesto.

Picture the scene. 

The developers are writing lots (and lots) of code. they are coding up a storm. 

The team is building great stuff. And you are learning more every day about the right combination of tools and techniques to meet the project brief.

So it’s all good, right?

Nope.

What I found was that doing all that work without proper structure was a bit…

Futile.

I’d heard about the agile manifesto. But use cases, sprints and all that jazz seemed like a mile away.

Then I heard this:

Make it work, make it right, make it fast

Kent Beck

Oooh. That struck a chord. That struck at my dark coders soul. 

And it came from the original signer of the Agile Manifesto

It still resonates loud within me now.

Why? Because it’s still the way I approach development projects now. In every project and for every problem.

Make it work

Freedom. That’s what this one means. Or it does to me. It means we can write whatever code we need to while seeking solutions. 

It doesn’t matter if it ain’t pretty.

It doesn’t matter if it doesn’t follow best practice. 

What does matter is: we have working code. We have a way to solve the core problem. 

Make it right

Now we fix it. We clean it up and we make it follow the rules. There’ll be tests and proper data structures.

There’ll be readable and maintainable code. 

And the code will still work (of course).

Make it fast

This one is not quite so easy to define. But it’s about stripping away stuff that doesn’t need to be there.

You can call it refactoring. You can call it restructuring or something else.

But in the end, you are clearing out the crud that has existed since the earlier versions. 

And there is always a deliverable

A big part of the agile manifesto is the frequent delivery of working software. 

Working software is the primary measure of progress.

Now, we all know that is a high aim, right? 

Working software is damn near impossible at times. Bits of working software? That’s much easier.

But that’s the point isn’t it?

Getting the working part right can take a long time. But being free from the constraints of architectural obsession is great.

You are more likely to deliver working software that way. 

Back to that coding storm…

You will write lots of experimental code (I know I have over the years). But the nice thing is: we can shove all that in make it work.

We are breaking it down in to small units so that something works. 

And that’s cool. Because we are heading for coding nirvana. Code that works and a deliverable. 

It might not be the whole deal yet, but we are on the way. 

Make it work, make it right, make it fast. 

Yes, code in that order is worth pursuing.

Here’s the million dollar question: 

How little code do you need to write to get something working?

Start with that. But always match it back to the brief. That way, you get something that works. You get a deliverable.

Your stakeholders will be happy.