Values – Practices - Tooling

Posted about 2 years ago on January 24, 2010

Something I heard recently really resonated with me and has already guided me on a few decisions lately.  I’m writing it down here because this idea has really caused a revolution in my mind.

The quote is this:

Values lead us to

Practices which mandate

Tooling

This envelops a lot of thinking and emotion I’ve had in my career as I’ve made choices about how to develop software that I haven’t been able to verbalize.  When I was young in my career as a developer I had that phrase completely inverted.  I made most of my decisions based on the tooling I was given.  For example: when I discovered how to generate 5000 lines of source code to do my database access I immediately leapt and made all my design decisions around that optimization.  Even when my code got complex and unreadable I just kept on thinking about how much time that generated code saved me.  “Certainly the time I’ve saved is paying for the sins I’m committing as I add line number 687 to this method!”

What are My Values?

After introspecting on this question I came up with 5 core values I have as a software craftsman (in no order):

  1. Quality (clean code that works)
  2. Simple designs
  3. Learning
  4. Creativity
  5. Team

These values have led me to these practices:

  1. Code designed by testing (TDD)
  2. Question abstractions before implementation
  3. Simple team communication mechanisms
  4. Continuous integration
  5. Practice (Execute, assess, learn, repeat)
  6. Improving
  7. Teaching

And ultimately because of these practices I use these tools:

  1. Low-friction source control – supports continuous integration and team integration
  2. Kanban board – supports simple communication
  3. Keyboard shortcuts wherever possible – continuous improvement
  4. Automated scripts - to take care of tasks requiring no creativity
  5. Frameworks that make testing user code easy
  6. Continuous integration applications
  7. …and other frameworks/libraries/IDEs/languages that support my core values

These tool choices have to be constantly re-evaluated.  The idea is that I’m constantly pushing to make the optimal solution feasible so that I’m supporting my values as closely as I can. 

Hat tip to Dave Laribee and Steven Harman for sharing this thought at Codemash 2010!

Tagged: Career

Comments

Bill Sempf writes...

I like this post - quite inspiring.

However, I notice a distinct lack of pragmatism. For instance, I noticed that you didn't mention that you value the needs of the business user, or getting the project done, one time and under budget, or making life easier for the people who will have to edit your code in 10 years.

I realize that you might think 'but of course I value those things, it is obvious so I didn't list them.' And perhaps you are right. If I were writing such a list, I wouldn't mention quality, becasue I feel that is obvious. Different strokes and all of that.

My only reason for mentioning this is to make you question if adding those things to your values would change the results. For instance, if meeting requirements is a value, does that drive a design process, and mandate a design tool?

Just my $0.02.

January 25, 2010

Steve Horn writes...

@Bill
Thanks for taking the time to reply.

When I was putting together that list I was putting myself downstream from the need for software and delighting the customer. If that need doesn't exist then my values and I are irrelevant. The values here apply to software construction and making the customer successful with that software.

Meeting the requirements is implied under quality, and it does drive a design process... Test Driven Design. I like NUnit and a simple runner such as ReSharper to execute the tests.

For communicating requirements and interactions with the end user I like tools like Balsamiq and/or number 2 pencils and paper to sketch mockups/wireframes.

Since I value quality over scope and budget, I urge(usually don't insist) my customer to flex scope in order to deal with the unpredictable nature of software development. This takes huge amounts of trust and respect from both parties, but it's worth it.

January 25, 2010

New Comment