For me, I like the intent of the phrase, but I don’t fully agree with it. For one thing, my personal view is that “make it right” and “make it fast” should generally go hand in hand and that if you’re making something right you will likely be making it fast at the same time.

Instead, I prefer to work to the mantra “Make it Work, Make it Pretty, Make it Right”.

Make it Work, Make it Pretty, Make it Right

The rationale behind my mantra is simple – “work, right, fast” only covers the quality of code, it does not look to the quality of experience. By merging “right” and “fast” into a single “right” rule and inserting a “pretty” rule the development process immediately becomes more concerned with how people will interact with what I’ve produced.

This process, by necessity, describes how I try to work as a single developer on my own on the train on my “itch to scratch” projects.

Make it Work

At the start of any of my projects I will have the germ of an idea that I want to flesh out, so I’ll start writing code. Obviously, making it work it pretty darned important to the whole process. At this point though, I won’t be too concerned about the elegance or performance of the code. What I’m looking for is for it to work; nothing more, nothing less.

To ensure the code actually works, I’m trying my best nowadays to create Test Suites that should be run before any code commit to make sure that I’ve not inadvertently broken anything. A quick look at my GitHub commits will show you that I’ve got a way to go in this regard, but I am getting there slowly but surely. These test suites become vitally important when you get to the “Make it Right” stage, but more of that later.

Make it Pretty

Once the code is working, and a test suite with good code coverage exists, it’s time to make what you’ve produced “pretty”. This could include (but is not limited to) improving the visuals of your site or application, writing documentation or even just making sure your code blocks line up nicely.

You see, “pretty” isn’t just about visuals. It’s about doing anything you can to make things easier for whoever comes later. That could be someone using the website you’ve just built, but it could just as easily be someone who’s trying to install your software on their own machine or the unlucky chap who’s got to fix a particularly nasty bug in the code you wrote.

This rule is the one that gets more people to use what you’ve created. Sure, some people will use the thing that works, but lots more will use the thing that works and is pretty.

Make it Right

The final step in the process is to make things “right”. The step is all about the “re” words – refactor, re-evaluate and reduce bugs.

Having a good test suite by this point is vital, because it gives me a huge amount more confidence in the fact that I can change how my code works without changing what it ultimately does.

And that’s that

So, there we go – that’s how I like to work. I’m not great at following everything in the mantra just yet, but I’m getting better. In time, I may even be awesome.

Oh, and for what’s worth, this post very much falls into the “Make it Pretty” rule. I’ve been trying to work to this mantra for a while, and now I’m documenting to make things easier for others to use if they want. And now that I’ve finished writing there’s the comments section, where hopefully you’ll help to make everything right for me.