DevOps Zone is brought to you in partnership with:

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 http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 520 posts at DZone. You can read more from them at their website. View Full User Profile

Coding: Tools/Techniques influence the way we work

06.19.2011
| 7689 views |
  • submit to reddit
Dave Astels mentions in his BDD paper that the way we use language influences the way that we write code, quoting the Sapir-Whorf hypothesis

“there is a systematic relationship between the grammatical categories of the language a
person speaks and how that person both understands the world and behaves in it.”


In a similar way, something which I didn’t fully appreciate until the last project I worked on is how much the tools and techniques that you use can influence the way that you work.


Distributed Source Control

Christian persuaded the client to allow us to use Mercurial for the project and it was interesting to see how we almost instinctively moved to a style of development which involved checking in much more frequently than we would have had we used Subversion.

There were still times when we’d end up working on something locally for too long but it seemed to become much more visible when this was happening and the endless ribbing that a pair got when they hadn’t checked in for a while ensured that it didn’t last for long.

I’m sure there are ways that we could have used Mercurial even more effectively than we did and my current thinking is that by default we’d want to use a distributed source control tool over any other.


Incremental refactoring

Incremental refactoring is a concept that Dave Cameron introduced me to about a year ago and it’s been talked about recently by Kent Beck and Joshua Kerievsky.

The underlying idea is that we know we want to drive our code in a certain direction but we want to do so in a way that doesn’t leave our code base in a broken state while we’re working towards that.

The techniques these two describe help to remove the fear and paralysis that we can often feel when we want to change a significant part of the code but know that we don’t have the time to do that all at once.


Not copying and pasting tests

I’ve previously mentioned a post Ian Cartwright wrote a while ago where he suggested that we should treat test code the same way that we treat production code, along the way pointing out that this meant copy/pasting tests was not the way to go.

I gave the non copy/paste approach a try last year and an interesting thing that I noticed is that when you have to type out the same types of things repeatedly you become much more aware of the duplication that you’re creating and since it’s costing time doing so you quickly look for ways to improve the situation.

Once we’ve got our tests cut down to the stage where removing any more duplication would also remove the intent of the test it doesn’t seem too bad to copy the outline of tests and then change the details.

We probably can move slightly faster by using copy/paste at this stage rather than writing everything out but the amount of time saved as a total of all development effort is minimal.

I think avoiding copy/paste puts us in a much more resourceful mindset and allows us to see improvements that we otherwise wouldn’t see and this it the real benefit of this technique.

Alan Skorkin has a cool post from a few months ago where he talks about the benefit of thinking about the code we’re writing rather than just going into auto pilot which covers similar ground.


Living prototypes

This is an idea that we used on my last project whereby we had a prototype of the website being developed alongside the real version.

This approach was necessary for this particular client but I really like the idea of having the real UI being developed alongside the code as it meant that whenever we showcased what we’d done to the client it was actually exactly what the final product would look like.

On previous projects we’ve often driven out the back end code and then styled it later which leads to a lot of questions about the UI when showcasing which may not actually be relevant when it’s properly skinned.

It also helped avoid the redundancy of showcasing something twice – once early on with just the functionality and then later on after the styling has been applied.

References
Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

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