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 534 posts at DZone. You can read more from them at their website. View Full User Profile

In a New Team, Observe First

  • submit to reddit

One of the most common instincts of a developer when starting on a new team is to look at the way the application has been designed and find ways that it can be done differently.

Most often ‘differently’ means that a pattern used in a previous project will be favoured and while I think it’s good to make use of experience that we’ve gained, we do miss out on some learning if we write every application the same way.

Therefore, unless I see a decision being made which is clearly going to lead to disaster later on, I now prefer to observe the approach being taken and understand its advantages and disadvantages before making a judgement.

A few years Jay Fields wrote a post titled ‘Kill Your Darlings‘ where he suggested the following:

You always gain by allowing someone to show you an alternative solution. If someone wants to solve a problem in a different way, there are several gains to be had. If their way is inferior, you have an opportunity to mentor a team-mate.

If their way is equally elegant, you’ve gained another solution, or point of view that may be superior in the future. If their way is superior you learn something new and the codebase improves.

In exchange for these gains you only need to give up time. Time is valuable, but it’s also well spent on improving the ability of a team-mate or your personal ability.

He was talking in a slightly different context but it seems equally applicable here.

One example from the current project I’m working on is that we’re not using an ORM tool but instead mapping from database queries to domain objects manually.

This is being done partly to get around the query optimisation problems we can end up with when using tools like Hibernate but it also means that we design our domain code properly and don’t get tempted to make it match the database structure.

I initially thought that it was a strange decision to write code to do mapping when you have a tool to do it for you but it hasn’t been as bad as I’d imagined although the data access code is pretty messy.

On the positive side we can directly measure the performance of each query, make the necessary tweaks, and then re-measure the performance much more easily this way.

The application is read only so we wouldn’t have got to use the full ‘CRUD’ repertoire that Hibernate provides anyway.

It might not be the right choice for the next application that I work on but I’m glad I got the chance to see what an application written without an ORM looks like.

Just observe!

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.)



Jose Smith replied on Fri, 2012/04/13 - 5:35am

It's an interesting way of looking at things.  I still feel that it's beneficial for a team to openly discuss these decisions especially for something fairly major like whether to ORM or not.  While "just observing" may benefit you individually (as far as acquiing knowledge), it may not benefit the product. 

If it turns out to be the wrong decision in the end, I'm not sure if my employer would be happy if I told him "I thought doing X might be beneficial, but I didn't discuss it with the team because it was an oppurtunity to learn something new" :)

Comment viewing options

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