Coding Up a Storm
Reading time: 3 minute(s) - 600 words
I develop via what I’ve taught myself. In that process I looked for a working method that would help. Enter the agile manifesto.
Picture the scene.
You are writing lots (and lots) of code. You are coding up a storm.
You are building great stuff. And you are learning more every day about your choice of programming toolchain.
So it’s all good, right?
What I found was that doing all that work without proper structure was a bit…
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
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 what I do (still) everyday. In every project and for every problem.
Make it work
Freedom. That’s what this one means. Or it does to me. It means I can write whatever code I need to while I’m seeking a solution.
It doesn’t matter if it ain’t pretty.
It doesn’t matter if it doesn’t follow best practice.
What does matter is: I have working code. I 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 do). 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 shit 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 quid question:
How little code do you need to write to get something working?
Start with that.