Category: Uncategorized

Katas and Insecurity

I’m at CodeMash today doing precompiler sessions, and I have to say that it has so far been a great time.

Today I spent most of my session in an “Improving Software Craftsmaship” session where we pair programmed several Katas. In the course of doing this, I found myself paired with a couple of people who were a bit faster to the punch than me on what needed to be done next.

Now, I’m used to this. My coworker Erik can always do basically everything faster than me, and believe me when I say that this doesn’t upset me. Erik is a friend, and I always appreciate his help. This was DIFFERENT though.

See, here at CodeMash, I’m walking around with one of the blue lanyards – I’m a speaker. So, when someone bests me at Katas, I feel like I haven’t lived up to some unsaid expectation. This caused me a bit of a panic attack. I found myself having to walk down the hallway and remind myself of these things:

  1. I am here to learn as well as talk
  2. I can practice and get better
  3. I have my own strengths

This post is admittedly trite, but I wanted to put it out there anyways as a reminder to everyone that, well, we all feel insecure sometimes.

Dog Breeding is a Craft

I want to depart a bit from posts on the craft of coding, and instead focus on another craft that is near and dear to my heart. That is the craft of dog breeding.

It is very popular these days to say things like “don’t shop, adopt” when people talk about getting a puppy from a breeder. I understand the sentiment behind these statements – with, indeed, lots of dogs in rescues and shelters, why would one adopt from a breeder? Lots of great people in the dog world have written great things about why breeders are still relevant, and I won’t rehash arguments that others have given. However, one argument that I don’t see often is one that’s very important to me as a software craftsman.

Dog breeding is at it’s heart, a craft. In the same way that carpentry, metal work, masonry, glass blowing, brewing, and many other arts are passed down from master to apprentice, so is quality dog breeding. It takes years to become a master dog breeder. Many dog shows, many trials, many conversations, many litters that you put your heart and soul into, many litters that don’t work out exactly the way you wanted. It takes mentorship to become a master dog breeder. Nobody becomes a great dog breeder without being mentored by one or more other great breeders. One starts as an apprentice and works one’s way to mastery.

Dog breeding is one of the oldest crafts known to mankind. Keep in mind that dogs have existed nearly as long as humans, and many anthropologists believe that large parts of the success of the human race can be attributed to our breeding dogs from wolves to be our early hunting companions. This means that we have been selectively breeding dogs as long as, or longer than we’ve been engaging in other ‘ancient’ arts like brewing.

Wouldn’t it be heartbreaking if nobody ever made a finely crafted piece of furniture again because Ikea furniture is cheaper and readily available? We would lose a piece of human history if that happened.

When people suggest that nobody should breed dogs until there are no more dogs in the world to rescue, people are suggesting the death of an art that is as old as time. If everyone stops breeding dogs, there will be no more mentors for the next generation. We will lose an art that helped to build the human race. We will have to relearn what people have been perfecting for thousands of years.

I’m hardly advocating that everyone who breeds dogs should continue to do so. In fact, most people who are breeding dogs would do well to get out of the business. But those who are truly participating in the ancient craft with dedication should be encouraged to continue and supported in their endeavors, in order to preserve a part of our history.

Does it Scale?

Raise your virtual hand if you’ve been discussing a problem in software and asked the question “Does it Scale?”

You are probably raising your virtual hand right now, because we as software developers LOVE to ask that question. Interestingly, when we ask that question, it tends to mean a lot of things. In general, it can be translated into two main, and very distinct, questions:

  1. Can the solution be easily changed to allow for more user traffic over time?
  2. Can the solution be easily changed to allow features to be added and updated over time?

The first question generally deals with things like adding hardware to servers or adding additional servers to accommodate load. The second question deals with what architectural patterns are used, how many unit tests are written, what development methodologies are used and how the solution is supported, among many other things.

A couple of years ago, I was in a three day training with Ayende about RavenDB. At the time I had just become a tech lead and was taking point on my first project, which was using RavenDB.

During a discussion of sharding, I mentioned that we might be interested in this feature. Ayende asked me to name the number of requests per minute that we expected to have, and the number of requests that we never expected to reach, even if massively successful – a practical upper limit per say. I wasn’t able to give a good answer to this.

I think this reflects a general trend of developers when interacting with the question “Does it scale?” Truthfully, I think we don’t know what the heck we’re talking about when we ask that question!

I would like to propose some alternative questions to “Does it Scale?” that I think enhance the way we think about our technologies.

  • What are my target usage goals and will this solution either allow me to reach them with a single server, or allow me to add additional servers to my cluster to reach my target usage goals?
  • Does my programmatic solution allow me to add additional servers to my cluster without issue?
  • Is my deployment story a maintainable one over time?
  • Is my code following SOLID design principals so the code base will be able to grow over time?
  • Are my tests adequate to allow for refactoring in the future?
  • Will simply adding additional hardware adequately provide for my growth needs?
  • Does the technology I’m considering using have a good DevOps story? Is it easy to deploy, configure, and keep in good health?

All better things to think about than “Does it Scale?”.