It started with Chad Fowler’s post on the art/craft/commodity continuum. This post was a reminder about the relationship that exists when you write software for others. In this relationship, there is a delicate balance between what the customer wants out of the relationship (working software) and what the developer wants out of the relationship (a chance to practice their art/craft).

Just yesterday, there was a flurry of posts discussing how the Ruby on Rails framework lacks some patterns that assure software quality in large scale applications and what we as the Rails community can do to help with this quality “deficiency”.

http://blog.steveklabnik.com/posts/2011-12-30-active-record-considered-harmful http://andrzejonsoftware.blogspot.com/2011/12/rails-is-still-cool.html http://karmajunkie.com/blog/2011/12/30/evolving-rails

Reading and discussing all of these posts with others has reminded me that there is no cut and dry measure of what makes a “successful” software project. It has also reaffirmed my two “golden rules” that I use to judge success with developing software:

• Always deliver software that meets the customer’s needs
• Always deliver software that is easy to understand for those that come after me

I would say that the first item is somewhat easy to measure objectively. The second one is a bit harder to measure objectively.

I wish I could impart some grand wisdom about what this looks like but I can’t do that. All I can say is that I surround myself with people who I believe are good software developers. When I get to writing that code that just doesn’t “feel right” or doesn’t “roll off my fingers”, I reach out early to those people for a review of the code in question. These interactions are where I refine my meaning of what “easy for others to understand” because I get real time feedback from someone who might just come after me in supporting the software that I write.