The importance of Attitude

I’m finding that attitude and intent make an important contribution to the code I write.

For example, though I currently use NUnit as my testing framework, and Rhino.Mocks for mocking, I’m not always using these to write tests or mocks.

Confused? Let me explain.

When I’m writing some library code for later use – a recent example is a dynamic UI framework – I usually start by writing consumer code, not library code. Adopting this perspective helps me to design the API in a way that is clean, clear and easy to understand – a perspicuous API, if you will.

As this consumer code is written, the requirements and specifications of the library will become clear – and these can be captured as NUnit tests. The key is to note that these are not so much tests as executable specifications. Though the methods are marked as [Test], they are actually much more of a [Specification].

The intention of the code (specification) is more important than the expression of the code (NUnit tests).

Another way that this manifests is how I answer the question “Is it Done?”

In the past, I’ve worked with developers who regard a piece of code as “Done” when it compiles and the main flow executes correctly.

Through bitter experience, I’ve reached a different point. To me, code is “Done” when I reasonably expect that no defects will be found in testing, and when a maintenance developer (who might be me, in six months time) can pick up the codebase and work out what is what without too much difficulty.

Again, this is an example of attitude and intention at work – as a productively lazy developer, my intent is to write code that never needs revisiting, and to ensure that any revisit that does occur is as short as possible.

What intent and attitude do you bring to your code?

(This post inspired by Chad Myers’ “How do you know your code works?”)