Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 543 posts at DZone. You can read more from them at their website. View Full User Profile

Coding: Write the First One Ugly

  • submit to reddit

I just came across a really cool blog post written a couple of months ago by Evan Light where he proposes that we 'write the first one ugly':

To overcome paralysis, for small chunks of code, it is often better to just write whatever comes to mind – no matter how awful it may seem at the time. Give yourself permission to let the first version suck.

I think this is a really good piece of advice and it seems along the same lines as a suggestion from Uncle Bob in Clean Code:

When I write functions they come out long and complicated…then I massage and refine that code, splitting out functions, changing names and eliminating duplication…all the whole keeping the tests passing.

I find myself following a similar approach to Evan these days whereas previously I'd probably have spent a lot of time thinking through the problem in my head trying to come up with a design I was happy with.

I agree with Evan that it's frequently easier to see a clean way to solve a problem if you actually have some sort of code in front of you even if it is a terrible solution.

If I get stuck I tend to copy and paste other code, break encapsulation of objects, write long methods and so on. Then after I have something actually working I'll go back and clean it up.

Sometimes I don't see a way to write a piece of code more cleanly so I'll leave it alone until the next time we're working in that area of the code base, an approach that Joshua Kerievsky expands upon in a post he wrote a few months ago titled 'sufficient design'.

I'll leave the final word to Simon Harris who made the following observation on twitter which I think is pretty accurate:

Ive said it before the difference between great developers and hacks is: the former clean up after themselves.



Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Aries McRae replied on Wed, 2010/10/13 - 6:33am

On one extreme, you have an analysis-paralysis type developer who spends too much time doing analysis and design on how to make his code highly flexible and configurable to the point that he never gets anything done.

On the other extreme end, you have a code monkey who spends little analysis and design but churns out tonnes of inflexible and hard to maintain code.

You need somebody who can strike a balance between doing analysis, design, could write code well, yet still get things done.

We've all experienced writing code with whatever comes to mind and the code turn out to be long and convoluted. You had every intentions of going back to it later on for refinement,
but go-live date looms and you simply ran out of time, so the support guy ends up inheriting your mess, because you had moved on to do the next release.

Here's an interesting blog from Joel Spolsky about Duct Tape Programmers who can ship code and get things done

Dmitriy Setrakyan replied on Wed, 2010/10/13 - 6:06pm

I'd be careful with this approach. As much as you think that you will come back and refine the *ugly* code, in majority cases you will not... and then you end up with *ugly* apps. If you take this approach, you must have a lot of discipline to come back and fix the *ugliness*.

GridGain = Compute + Data + Cloud

Robin Bygrave replied on Wed, 2010/10/13 - 9:31pm

I agree with the Hippy Hacker. I might say it a slightly different way though:

... "Always assume the 'first cut'/version needs (maybe significant) Refactoring."

Generally you have imperfect knowledge when you start and if the problem is complex you should not expect to get the initial design right (the more complex the problem the more refactoring cycles should be expected).


>> As much as you think that you will come back and refine the *ugly* code, in majority cases you will not.

I'd say it's a mindset and a work plan that you can employ in your team if you wish. ie. Everyone in the team should expect 'first cuts' to be refactored (sometimes brutally) and that's ok because people now have more knowledge of the problem. Code reviews/refactoring should be incorporated into the work schedule with buy in from project managers.

Jon Ericson replied on Thu, 2010/10/14 - 11:07am

My first one is always ugly. And my second. And my third.

Loren Kratzke replied on Thu, 2010/10/14 - 3:02pm

Of course the first cut should be ugly. In fact, often times my first cut is nothing but copy pasted examples from the web with main methods and System.out.println() statements dumping arbitrary data to the screen that I use to discover which approaches I should use to solve my problem.

Once the basic libs are selected, I do my first alpha that begins to tackle the problem. More System.out.println() to monitor the progress of the logic.

Next, my second alpha (built from the good parts of my first alpha). This one usually takes the first real bite out of the problem. Now I have a final strategy and clear sense of direction.

Lastly, beta, beta, then RC... Unit tests are last. Sorry TDD people, that's just the way I roll. And my finished products are premium without exception so I don't even want to hear about this TDD nonsense.

Andy Leung replied on Sun, 2010/10/17 - 2:18am

I really hope my friend would have read your post, he wants to be a programmer but I have been telling him since 2005, just to try writing a simple program in Java and no matter how bad it would be, it would be a good lead to next level.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.