Mark Needham

Thoughts on Software Development

Coding: It’s all about the context

with 9 comments

I think one of the easiest things to do as a developer is to look at some code that you didn’t write and then start trashing it for all the supposed mistakes that the author has made that you wouldn’t have.

It’s certainly something I’ve been guilty of doing and probably will be again in the future.

Sometimes it’s justified but most of the time we lack the context for understanding why the code was written the way it was and therefore our criticism is not very useful to anyone.

I think the more projects that I work on the more I realise that there’s no single set of rules that we can apply in all contexts.

I think rules or principles do still have value but we shouldn’t rigidly stick to them, but be aware when there is more value in not following the rule and then go for it.

To give a simple example, one of the forms of good practice when using the NUnit testing framework is to minimise our use of the TestFixtureSetUp attribute and instead use SetUp so that the common bit of code is repeated before each test is run rather than one time before all the tests are run.

One time when we found it useful to break this rule is when writing tests for mapping code when there are a lot of different things to assert and only one method call to make.

Using our normal approach of keeping each test as it’s own little specification resulted in tests that were really difficult so we broke the rule and using an approach which resembles the context/spec approach to driving code.

Looking at that code without the context of what I’ve just described you would probably think that it’s terrible code and that we don’t know how to use the framework but in this case it actually made our lives easier so I think it’s fine to break the rule in this case.

Another example is passing booleans into methods – in general I think this is really bad practice but it actually helps to significantly simplify code when we pass them into HtmlHelpers so that it knows whether to render the read only version of a control or not.

I’m not sure who said that ‘if you rewrite a system that you didn’t write the first time you’ll probably make the same mistakes as the original team did’ but it’s certainly becoming more clear to me how this would be the case.

The conclusion I’m pretty much coming to is that it’s great to follow a set of practices, and doing so helps ensure that we are doing the right thing most of the time, but having the flexibility of thought to step away from that and try something different is very important.

Be Sociable, Share!

Written by Mark Needham

April 5th, 2009 at 7:45 pm

Posted in Coding

Tagged with

  • Pat

    I like to use the term guideline over rule because I think guidelines are better viewed as advice, not something to simply be followed without thinking about.

  • I’d agree with that – probably not as interchangeable as I’ve used the terms in this post.

  • Rob Hunter

    If I find myself breaking one of the conventions that we’ve generally come to value, I like to leave a comment explaining what I’ve done and why this time it was better to “do it wrong”.

    This helps give the context that you mentioned, and helps avoid “trash talk”. It might even be that the circumstances have changed since the comment was written, so the break from convention is no longer needed.

  • Hi, Mark

    Thanks for sharing your reflections on this fundamental but often neglected issue.

    I fully agree that design decisions shouldn’t be evaluated solely on the basis of generally accepted principles and rules. The relevant contextual aspects must be brought into the design process.

    Indeed, I think the context is so important that even refactoring shouldn’t be absolutely constrained to the program texts. The program context points the best directions when we advance beyond trivial structural improvements.

    This issue resonates deeply with me. I have been reflecting on this, as part of my learning journey, at


  • Hey…
    Great post mate!!!

    The beginning of it is very aligned with Nat Pryce’s theory about:
    “Complaining about Other People’s Code”…. It’ss

    Check it out…


  • Pingback: Software Quality Digest - 2009-04-06 | No bug left behind()

  • Adam Lider

    “Looking at that code without the context of what I’ve just described you would probably think that it’s terrible code”

    I would say: Looking at anything without the context can lead to wrong conclusions.

    Everything has some context. Sometimes the context is obvious but we should not assume like that.
    A little different example:
    The one of the most problematic thing in soft-dev are estimations. The only possible to way to estimate anything is compare it to something “similar” what was already done. It requires a lot of expertise to take right context (not to deep and not to shallow) to make a decision that “cost of x is like (or twice as) y”. Unfortunately (soft-dev) people many times don’t even try to think a while about the context before making decision/giving estimation/judging design or code.

  • Pingback: Coding: Passing booleans into methods at Mark Needham()

  • Pingback: Pimp my architecture - Dan North at Mark Needham()