I've been reading plenty of blog posts about Software Craftsmanship including a nice response by Uncle Bob. I ran a Software Craftsmanship precompiler workshop at CodeMash again this year, and I've even seen some good feedback and follow up from attendees. If you're in the area, I really recommend coming out to CodeMash next year. I am hoping to be there again next year doing the Software Craftsmanship precompiler.
Back in 2009, Steve Smith, Rich Henning, and I got together and discussed how we were going to create the Hudson Software Craftsmanship group. We figured out some times to meet and what types of exercises we would do. The group has had a steady group of attendees over this time period. We use a room that if we're prepared can fit about 30 people. Our usual group is between 15 and 25 people who show up ready to discuss software craftsmanship, values, principles, practices, unit testing, quality, and just about anything else. We get just enough people to have some really great discussions. Our next meeting is actually tonight and right now we have 28 people signed up for the event. We found some things to focus on and we did. We're all about lightning talks, discussions, and improving our coding abilities.
In short, I've got Software Craftsmanship on the mind right now. I might as well spend some time discussing it.
I think Software Craftsmanship started as a good banner to rally behind in the fight to end crappy code. There are plenty of reasons why code might have been crappy, and I am all for rallying behind the banner of good, clean code. We're not talking about agile or lean when we talk about Software Craftsmanship, however, most craftsman are also supporting lean practices. In software craftsmanship we focus on the people, their relationships, and the code they write. I think in this sense, Software Craftsmanship can apply for any agile methods you use or even on a waterfall project. We're talking about writing code that fits the situation, which means in a lot of cases we need to cut down on the crap. We're more than that though. We're about making customers happy (sometimes the customers are just our bosses.) We are also trying to become better developers as a community. We need to help each other. The best developers in the world are the ones who have learned from other developers. You can never be great if you don't learn from others.
One of people's favorite terms to use is quality. It really has a meaning that is easy to define in generic terms, but is very difficult to nail down in terms if a quantity. I think we could all define quality in some way, but I think that we cannot determine the quality of code very well. It is very subjective, since people's definitions of quality and how they apply it are different. I think, however, that it is a central point in Software Craftsmanship. For that reason it is something that we should strive to understand and evaluate. If I were to give an important trait for a Software Craftsman to have it is the ability to determine and evaluate quality. Use whatever measure you like, but be able to understand quality and how to evaluate it depending on the circumstances of the code you're writing. Your definition of quality need not even match everyone else's.
A topic that I've heard Steve Smith argue with people over plenty of times is whether or not a software craftsman should knowingly write low quality code. This usually comes up when the customer specifically wants you to write crap. The customer might even say that they'd rather have the product done sooner with bugs rather than have the code take any longer. I've heard some good arguments on both sides. To throw my two cents in, I'll just say that it really depends on the situation that you're evaluating.
I didn't have as good of a perspective on this topic until a great discussion on this very topic broke our during a HudsonSC meeting in which Joe Brinkman gave some very good arguments for why a software developer might not want to put extra time into code. His point was that for a startup, there is a better than average chance that you will be throwing the code away soon. You do not know if this code will ever be used again. It might be gone in a few months.
I admit in most situations I would argue for having higher quality code, but in the case of a startup I think there is good reason to write code fast and get something working. I think it is assumed for some startups that their code might have bugs or other issues. My interpretation of what Joe was saying is that the business might not even be a good one, so in those instances the software need only provide the basic functionality of the idea. If it is missing features or has some bugs you can still tell if the idea is something that the market is interested in. Startups have a completely different mindset. You need to quickly and cheaply find out if the business idea is going to work before your run out of funding. If I am interpreting him correctly he is basically talking about throw-away businesses not just throw-away apps. You keep starting and tossing businesses until one of them succeeds. I think in this situation, the code can reflect the business. Once the longevitiy of the business is determined, quality can be brought back into the mix.
To look at things from a different perspective, we can take the groups of people we have that attend HudsonSC who work at banks, insurance companies, and healthcare companies. All of these are long-standing businesses that need to maintain quality code at all times. It is these who have the traditional opinions on SoftwareCraftsmanship. These groups have no reason to lower quality. In fact if they don't maintain quality, they could have serious issues. I think most of us are in the boat where we expect the business we're working for to still exist in 6 months. This means that our code needs to survive and maintain for years after we first write it.
A software craftsman should know what customers want and be able to provide code which offers the value the customer is looking for. It is up to a craftsman to determine what solution is the best one for the job and be prepared to provide the highest quality code possible. In this instance I will say that the level of quality in the code is one that should be determined by the developer and the customer.
Comments