Brendan Enrick

Daily Software Development

CodeMash 2014 Software Craftsmanship Precompiler Workshop

CodeMash 2.0.1.4 started as one of the coldest CodeMashes on record. On Monday, during the set up time for the event, the temperature in Sandusky dropped below negative ten degrees and the wind chill kept it feeling much colder. It was severely lacking in snow, but the cold was enough to cancel many of the Tuesday precompiler sessions whose speakers were not able to arrive at CodeMash on time to run the workshops.

The conference has grown to the point where it now has two initial days of workshops on Tuesday and Wednesday. Then the conference has two normal conference days filled with sessions. Considering that all of my favorite content is always the precompiler workshops on the first two days, I would love to see the conference have workshops through the entire event. I am usually one of the precompiler workshops speakers, so I might be a bit opinionated on that. From another viewpoint though, since I am one of the speakers during that time, I am often wishing I could attend workshops during the same time as mine! I love running the workshops though, so I gladly give up the other ones. I just need to figure out how to be in two plaes at once (future goal).

CodeMash Precompiler Workshop Details

For those who attended my and Steve’s Software Craftsmanship precompiler workshops on Wednesday, the weather was much more forgiving. Most people had arrived by that point, which meant that our attendance was also good. This was the fifth year that Steve and I had run this precompiler event at CodeMash. We adjust, change, and update the workshop every year. In the past, we had to teach a lot more about the basics of unit testing, but now more people have at least some knowledge of unit testing.

Over the years of doing this workshop here (and similar ones elsewhere), we've found a lot of good techniques and exercises for working with the attendees of the event. We try and experiement with lots of exercises and katas at conferences, events, and user groups, because we're looking for great ways to teach these types of events. When we run them, we are always trying to make sure that most of the event is spent coding. Through this, our goal is not to give an exercise to the attendees. Our goal is to teach them how they can continue their exercising and learning after they leave the event. That's our goal.

We use a few types of exercises: gateway exercises designed to teach you how to practice, guided exercises leading you down a path slowly with steps for freedom along the way, and open-ended exercises giving great freedom and possibilities in final implementations. As part of the open-ended exercise, we often attempt to use that as a plane up which to build a specific type of implementation. We will choose a principle or a pattern and use this plane as an area in which to practice following the principle or pattern. This shows the students how they can leverage programming exercises as places to learn new principles and patterns.

Beginning Software Craftsmanship Workshop

In the morning, we start out our session for beginners just learning software craftmanship. This course is for people familiar with programming (using any language) that want to learn more about software craftsmanship and work on programming exercises with their peers.

As we do every year, I started off the discussion by explaining software craftsmanship and giving an introduction to its concepts. I explain the software craftsmanship manifesto, what it means to developers, and how it relates to the agile manifest. Through this talk, I always make sure to emphasize the importance and reasons for deliberately practicing. As the entire audience will agree, when under a deadline they jump back to their poor practices they know aren't the best. Practice is how we drill ourselves to handle the situation in our own desired way. I make sure that the audience knows as well as discussing and working with others. If I can encourage more people to attend and start software craftsmanship groups, I would consider this talk a great success.

Introduction to Software Craftsmanship Slides

Once we had the reason for why we're all here, we start getting into some of the meat of the workshop. Steve then presented his well-honed talk on software principles. Most of them are designed for object oriented programming, but many are applicable to nearly any language or paradigm. Along the way he of course will cover SOLID, and the slides all contain images from our Software Craftsmanship Calendar. The 2014 edition of the Telerik Software Craftsmanship calendar is out, and everyone at CodeMash received a copy of the calendar.

Software Development Principles Slides

While Steve is wrapping up the end of his presentation, I start passing around sheets of paper (yes, real paper) containing a printing of the first exercise we'll be doing. For our first exercise, we were doing FizzBuzz an exercise that is simple enough that it gets people used to the idea of practicing. This is our gateway exercise. We use this to make sure that everyone is set up with their tools. As long as their setup allows them to write code and run tests, it should be good enough. We include some extra credit with these, so that most people can at least get close to finishing the first part of our exercises. Some people will finish the extra credit, which means that we can have nearly everyone reach a stage of accomplishment. 

We also ask that the entire group pair up, so that they can work on the exercise with others. This accomplishes quite a few things, including helping those who don't have a computer with them.

FizzBuzz Programming Exercise

Interrupting everyone's coding is always a challenge, but I make sure to do it nicely. A microphone helps with this! Now that everyone is set up, we take a break from the coding to talk about practices that we promote to the group. The first of these practices is testing. As is still the case, most people are testing or at least familiar with the practice. As a result, I cover this topic briefly making sure to emphasize the different types and their importance. There are still many groups forced to write integration tests instead of unit tests for example. We discuss how to avoid that situation in the afternoon when we discuss more good practices. 

The second practice that we discuss is continuous integration, however, since we don't have the time to set these up on everyone's computer, we only discuss this briefly and suggest that people try them.

The third practice is pairing, a practice that we've already had the group start in their first exercise. Not only do I cover the methods of pairing, but I point out all of the good pairing practices that everyone was using without thinking. I then point out the importance of changing partners and typists frequently. In their first programming exercise, very few people change who is typing. Since pairing is such a hard activity, we also make sure to cover all of the things that you can do to improve your pairing by changing the environment in which you're working.

Software Craftsmanship Practices Slides

The String Calculator is a guided exercise in which you only read one step at a time. Each step has parts to it, but you do them one at a time. This follows the normal scenario of receiving your requirements a piece at a time. It also keeps you following a plan and gives you a great chance to follow YAGNI. The students do well with this, and it's an exercise that does very well on paper, since you can fold the sheet over the future steps. 

String Calculator Programming Exercise

Intermediate Software Craftsmanship Agenda Workshop

After lunch, we started our second workshop. This one is a half-day workshop designed for people who attend the morning workshop or are already somewhat familiar with software craftsmanship, deliberate practice, or who just couldn't fit the morning session into their schedule. 

Steve starts off the talking in the afternoon discussing design patterns. Steve is an expert in design patterns and refactoring, so he's a great person to present this workshop with. Steve covers a lot of design patterns in this talk. You'll notice that a lot of these patterns have overlap and many of them stem directly from one or more of the principles mentioned in Steve's morning talk. This is not a session to miss!

Design Patterns Slides

Once we're done with the design pattersn talk, we make sure that we start everyone on an open-ended exercise. This year's was the greed dice game scoring exercise where you create code that will score the results of one roll in the greed dice game. It's a simple exercise, but can get a bit unwieldy if you're not refactoring or implementing a good design. We don't suggest that anyone try any specific design for their first attempt.

Greed Game Programming Exercise

We follow up this programming with even more programming practices to follow. I do this talk, which is about more advanced types of testing using mocks, fakes, stubs, etc. We want to make sure everyone knows how to do these. We sometimes do an exercise that can leverage these skills, but we did not this year. We instead showed a quick demo of doing this with a logging system that logs to the file system.

Advanced Testing Practices Slides

Back to Greed again for the final exercise of the day. We finish out the workshop asking everyone to program the Greed game scorer again. This gives the students the chance to attempt a more complex solution to the problem this time around. We had everyone attempt to implement a Rules Engine for the second attempt, which will allow them to follow the Open/Closed Principle.

Overall we received a lot of wonderful feedback from our students, and I hope that everyone who attended goes on to continue doing what we taught in that workshop. Thank you all for attending. Thanks CodeMash for putting on a wonderful event and inviting me and Steve to run one of your precompiler workshops. It is always a fantastic time! I look forward to seeing more of you there in the future. Have a great 2014!

2014 Software Craftsmanship Calendar

The 2014 Software Craftsmanship Calendar is now available for preorder!

If you were a fan of any of the previous Software Craftsmanship Calendars or just liked the posts about some of the months, you'll be glad to know that we continued making a new one. We are continuing to alternate between Good Practices and Bad Practices, so this year (being the 4th) is a calendar of anti-patterns.

Each month of this calendar shows something that you shouldn't do, but plays it off as a good thing. You'll also find an interesting, related quote and a definition of the anti-pattern on each month.

Go get your calendar today!

Waterfail

One of the agile communities mocking terms of the old-fashioned Waterfall development technique is, “Waterfail”. It is called this, because the community credits this technique with being part of why a lot of projects fail.

The main difference between this technique and most agile techniques, is that waterfall does one big flow of everything. It does not loop through the process as most agile techniques do. It attempts to have everything planned out so that you’re just going through the motions toward success.

I’ve been posting each of the topics from the NimblePros software craftsmanship calendar as we get to the month. With each of these, I am mentioning that you should work on trying to follow the good practice or avoid the anti-pattern. Since this year’s calendar is on anti-patterns, it included Waterfail as something to avoid.

So for the month of August, I am going to recommend trying to move away from Waterfall. I’m not saying that you should suddenly move from a Waterfall project to some form of an Agile project. At least start looking into the possibility. Read a book on agile, go to an agile or software craftsmanship user group, access online resources for learning agile techniques, or attend a conference with an agile track.

Waterfail

I really liked how well this image turned out, and if you didn’t notice, we wrote “Waterfall”, but we cut part of the first “L” to make it appear to say “Waterfail”. Just one of our subtle little tricks in the calendar.

Go here for a more thorough analysis of Waterfall.

Boy Scout Rule

When and how much time to spend refactoring out code is one of the best questions that a budding software craftsman will ask. It’s one I’ve asked and answered many times. There isn’t one specific answer that is better than all of the others. It always depends on your personal preference, the restrictions of you client, company, or team, your code base, your language, your version control, and many other issues.

One rule, which is the one that I follow and encourage others to follow, is the Boy Scout Rule. It’s based on the “leave the campsite better than you found it” idea. It’s often said to be a line related to the scouts, but it seems to work well for code also.

If you have some old code that needs refactoring, I would guess it’s not tested. Since it’s not tested, you run the risk of creating bugs even if you’re testing it while refactoring. Some small changes will need to be made in order to test the code. You could miss something. That makes it dangerous. This is why you want to keep your refactoring to small pieces at a time. When and where you refactor are the next questions.

The Boy Scout Rule answers these questions nicely. You want to refactor the code you’re working on now. It’s fresh in your mind. You know how it’s supposed to work since you’re in there making changes now. It obviously is a volatile place, which should be cleaned up. You’re in there changing it now aren’t you?

Plus your current change might make things worse if you don’t do a bit of refactoring first!

The 2011 NimblePros Software Craftsmanship Calendar featured the Boy Scout Rule in the month of July, so for the rest of July, try to do small pieces of refactoring as you go into parts of a legacy codebase. Rewrite some code, write a test if you can, update an outdated comment (if you don’t just remove it), or even just write a better variable name.

It’s all about incremental improvements. The agile community should be loving this rule, since it is all about incremental changes and improvements.

Boy Scout Rule

Enjoy the rest of July! Don’t forget that you should also be avoiding Feature Creep.

Feature Creep

We’ve all been there before. Our project is moving along just fine. The release date is in sight. We’re on track to get everything pushed out right on schedule. Then everything is derailed by a last minute must have new feature. Maybe it’s the differentiator that will raise your product out of the crowd. Perhaps it’s just one small feature that will only push back the release by a day or two. When you’ve finished that one, however, will you have any additional must have features?

This is called Feature Creep. It’s when new features get added to the scope, and often, these features will cause delays in the project.

As a proponent of agile development, I approve of clients adding new features, however, it’s important to understand that adding in a feature should mean replacing a previous feature or you’ll have to push back the release date. It’s important to understand that with many (certainly not all) software projects, you can update the software at some point within the next few months with new features. It’s important to release something to the client. Adding on more and more new features right before a release will just mean a delayed release.

The NimblePros 2012 Software Craftsmanship Anti Patterns calendar for the month of July is about Feature Creep. So for the month of July, make sure that you watch to make sure that your scope is not ever increasing and pushing off release dates. Shipping is a feature, and your product should have that feature also. If you keep pushing off the release date, it will never ship.

FeatureCreep

Once the airbag, rocket boosters, seat belts, and parachute are added to this bike it will be done. Oh. And an ejector seat. We also need to add spokes, so I can put a baseball card in them. We need a bell too. And a horn. It won’t take long to paint it blue will it? Can we add padding to the seat? That’s the last feature. I promise. Oh I forgot about the mud flaps. Once that’s done we can ship it. As long as there are pegs on the back for passengers.

The Clean Coder Review

I recently read The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series), and it is one of the best books on software development that I’ve ever read. The book is a quick read from Uncle Bob Martin and is comparable in size to his similarly named, Clean Code: A Handbook of Agile Software Craftsmanship.

The book goes through many, many examples from the author’s development experiences. It has sample discussions between parties to explain points and really goes over professionalism in software development.

The Title

The impression I have about why the book is called “The Clean Coder” is mostly a play on professional developers wanting to have clean code. This doesn’t just mean the code, the code is included of course, but it also means that the whole coding experience and the whole project should be clean.

There are a lot of mistakes that developers can make, and the book is covering them and discussing how to keep things clean.

The Material

Without jumping into too much of the meat of the book, I will say that there are many things in the book that I’ve done before and don’t do anymore. There were some things mentioned that I’ve done recently, and I am going to make sure I never do again. There are some things in there that I’ve thankfully never done, and I hope I don’t ever do them.

The book focuses on a lot of bad situations, why these situations are bad, and how we should really be handling things.

Consider this book to be a guidebook of suggestions for how to act as a professional. For example, in the book’s discussion of estimation, instead of focusing on how to be more accurate with estimation, it covers how you should be estimating. This means that it tells you that you should be very clear about things being estimates, not to imply a commitment, and not to make commitments if you cannot meet them.

Controversial Points

The Clean Coder makes some recommendations that I am sure that plenty of people will disagree with, and the way some points are worded cause me to sometimes disagree as well, but I don’t think it really takes away from the value of the book.

One example of this type of suggestion is that you work 40 hours a week and then another 20 each week on improving your career, leaving 56 hours for sleeping and 52 hours for everything else. It’s presented as doing this makes you a professional and not doing it is not professional. What I disagree with is the definite amount of time. I think it’s important for people to work on their careers, but 20 hours is arbitrary here. Someone may get the same value out of 10 hours that requires me 30 hours. There also is no definitive line between professionalism and unprofessionalism. There are some gray areas, and I believe this would be one of them.

Some things in the book were kept clear that it’s how he works, and I took these as suggestions to learn how I work and make sure that I am evaluating a possible issue.

In this case, I am referring to a point on music. Some people listen to music lightly while programming. This is even true when pair programming. I sometimes like having a very light bit of background buzz from music while pairing. In this case, I keep it so quiet that we can still communicate easily. The book seems to be against music, since it distracts and changes the author’s thinking. For me, I think I don’t have this issue because my pairing partner prevents a change in thinking. I also try to listen to music with foreign lyrics or no lyrics at all. It also helps to not distract from the task at hand. The value here for me is that I should be evaluating and thinking about how I am doing things to make sure that something as seemingly inconsequential as music is not detracting from my work.

Meetings

One great suggestion made by Uncle Bob is that it’s OK to decline a meeting invite. I think that’s very important to understand. Unless you’re really needed in the meeting, you should try not to attend. Meetings take up time, and if it’s less important than your other work, you shouldn’t be attending.

I had a meeting I scheduled yesterday. I invited 8 people to that meeting. I made sure it was clear that if you had something to bring up, you should attend the meeting, otherwise your attendance was not required. We had 4 people in the meeting, and I think 1 of the attendees need not have been there anyway.

Trying

You should read the section on trying. It’s important not to try, and this book makes it very clear why. If you’re going to try, you’re making a commitment to try.

Mentoring

The first paragraph on the chapter on mentoring illustrates one of the biggest shortfalls of the software development industry. I owe a lot of my successes as a developer to the mentoring that I’ve received through books, blogs, and any other recorded sources of information I can get my hands on. I was also lucky enough to have a mentor and a role model to learn from as I became a better developer.

Summary

If you go in to this book expecting it to be a recipe for success, you will be mistaken. This book is fantastic, but it’s important to think and consider why it’s valuable. It is one developer’s experience as a developer.

From his own stories, he is a developer who has hit some pretty rough patches and made some terrible mistakes. That’s a good thing! It means that he has learned a lot!

While reading the book, I never felt like it was forcing his way of doing things onto me. It is presented in a great way to inspire changes in the developers who read the book. You don’t have to do the same things that he is doing, but try to consider what the right answer should be.

The examples are simplified for the book, and business are more complex than what is in the examples. The reader will need to adjust and make decisions, but that’s what you should be doing anyway. Think about being professional and doing what you should be doing.

This book has been on my intended reading list for a while, and now I am going to recommend it to other people.

Well done, Uncle Bob. Thank you for sharing your experience with everyone.

Try Writing Try Methods

When I say "Try Methods", I am of course referring to the common prefix "Try" on a method, which implies that the method is going to attempt to do what you're asking by using an output parameter for the operation and using the return value to indicate whether the attempt succeeded.

The common ones that people see in the .NET Framework are the TryParse methods, which attempt to parse something and if it can't be parse, they assign the default value to the output parameter and return false. If the succeed, the parsed value will be placed in the output parameter and the return value will be true. If the code failed, the convention is to use the type’s default value to assign to the output parameter. This lets you write code like this:

int someNumber;
int.TryParse(userInput, out someNumber);
// use the number entered or the default 0
int result = 1 + someNumber;

 

This is also great when you're going to be checking whether the method succeeded. In fact, you can use the try method directly in the if block, which usually makes things nice and clean. Here is an example of using them like that:

int someNumber;
if (int.TryParse(userInput, out someNumber))
{
    // Do something with someNumber
}
else
{
    // Invalid input: handle this case accordingly
}

 

Yes, you know all of this and have seen it before, however, are you writing these types of methods yourself or is your only experience with them the standard TryParse ones?

What I am trying to emphasize here is that you need to write your own Try methods in your code. You will thank yourself later.

Everyone can see the obvious benefit of not having to check for the default value to see if it the method worked. You also don't have to have ugly Try-Catch logic in your code. You get an if statement instead.

The real benefit of a writing a Try method has nothing to do with what I've already said. The most important benefit, in my opinion, is that you have a return value from it that isn't the value you are using for your logic. By having this return value for its success, you have to decide on how to handle the case where it failed.

There are important cases that might be forgotten, but having a return value means that I need to handle the return value. When I have it, I need to decide what to do with it. There may be a message I need to display to a user. There may be logging I need to do. I might be able to ignore that case. What is important, however, is that I thought about how to handle it. I had the chance to make sure that I handled the case correctly.

Create your own “Try” methods. I recommend looking into creating your own “TryParse”, “TryGet”, TryDelete”, and anything else that has a chance of failure that you may want to handle.

Groundhog Day Experience

One of my all-time favorite movies is Groundhog Day. In the film, the main character, Phil, repeats the same day for thousands of days. I've heard rumor before that the author said that Phil had repeated the day enough times to have been trapped in the loop for 40 years. I don't know if the author really said this, but it seems like enough time to have learned and experienced everything that he claims to have experienced in the film.

I believe this comedy offers a lot more meaning that what it appears on the surface. I think that we should all be striving to live our lives as Phil did in this one. No, ignore all of the silly, crazy, and suicidal days. Focus on the days where he was focusing on improving himself. Phil did a great thing in motivating himself to learn to speak French, play the piano, and genuinely change his character and outlook on life. He attained many artistic abilities and social skills. He also learned a great deal by varying his days. He repeated the same day over, but he never really repeated the day the same as he did before.

One of the greatest weaknesses that we as humans have is our urge to do today the same things we do every day. If we don't get out of our confort zone and try new things we will never learn, grow, or master anything new. I think I should strive to live my normal life more like Phil's. 

I've heard the reverse mentioned about many of the developers in our industry. On many occasions and from many people, I've heard the saying that someone may have 10 years experience, but it's really 1 year of experience repeated 10 times.

That terrifies me. I really don't want to fall into that situation. i want to make sure that I am always learning and growing as a developer. I look at my code from 5 years ago and can't believe I wrote things that way. I look at my code from 6 months ago and am also glad I've improved. Ten years from now, I hope I will still be saying the same things about my past code. I also hope that the software I am writing, the languages I am using, and the patterns I am folliwing are vastly different from the ones I am using now. That will mean that I am improving my skills as a developer and improving myself.

The best way to describe this is to say that Phil took one day and expanded it to more than 10 years of experience. As developers, we should make sure that we don't condense 10 years of experience down to 1 of fewer years.

Try new things and continue improving.

Coding Katas and Exercises

The following post is a list of useful practicing resources. These include: coding katas, programming exercises, and educational software development games.

If you’re not sure why you should be doing coding katas and exercises, I have this old post explaining the benefits of coding katas.

Coding Katas

Games

  • Agile Ball Flow Exercise (imagine the 1990s under construction gif here)
  • Agile Pizza Shop (imagine the 1990s construction gif here)
  • Marshmallow Challenge (imagine the 1990s construction gif here)

Recap Posts About Katas, Exercises, and Games

Why to Join a Software Craftsmanship Group

Like other professional community groups, a software craftsmanship group is supposed to offer benefits that would make a working professional take time from their schedule to attend. These benefits come in many forms: networking, support, feedback, education, self-improvement, and the list goes on. Not all of these benefits will resonate with everyone, and there are plenty that I did not name applying to many individuals and situations. A software craftsmanship group can supplement or replace an existing group that you’re attending.

A common complaint that I hear from attendees of other groups is about how the discussions at dinner after the meeting is the most worthwhile part of the meeting. When I hear this, my first instinct is that these people need to start going to software craftsmanship meetings in addition to or instead of their current groups.

What is Software Craftsmanship?

Software craftsmanship is often described as a movement in the software industry of like-minded people who believe in a set of values which can improve the software we write. The Software Craftsmanship Manifesto describes in what these like-minded individuals believe.

I’ve often found it interesting how the Software Craftsmanship movement seems to be an extension of the agile software development movement. I and most of the members of the Hudson Software Craftsmanship group are all developers who either work at companies follow some form of agile development or are trying to move towards it. In fact the 4 main values described in the Software Craftsmanship Manifesto specifically describe how in the attempt to achieve the values described by the Agile Software Manifesto these ones were found to be indispensible. It is the idea that pursuing one set of values that have proven to be very useful, another set has been found to be extremely valuable.

Dispelling Misinformation

There are some people who have bad opinions of software craftsmanship, and I’d like to take some time to address some of those concerns incase any readers have heard of them or share them.

It’s not elitist.

I’ve heard software craftsmanship referred to as being elitist. In my experience, this is entirely not the case. I would believe that there are people among the community that fit this description, but those people would be outliers. We are welcoming of people of all skill levels who are looking to write cleaner, better software. I for one don’t even think that everyone will or even should be software craftsmen. If you enjoy the way you’re doing this, by all means continue. I don’t believe that my methods, practices, values, and beliefs are any better than anyone else’s. We are a group that shares our beliefs and want to work together to improve ourselves.

It’s not ALT.NET.

I’ve heard Software Craftsmanship compared to ALT.NET by some people, and I can see why the comparison would be made. Both are movements in the software industry to try to do things better than we have been doing them in the past. The ALT.NET community is like-minded individuals in the .NET community who are against the direction, guidance, and tooling that has/had been coming from Microsoft. While I do not follow that guidance either, I am not openly against it. In fact, I realize that the methods that I believe in and use in my own development will not work for everyone.

Software Craftsmen will help each other move away from that tooling and guidance, because the people we are helping want to move away from it. For many developers the control-based, do everything for me approach that often comes with that tooling is perfectly acceptable. There are many developers who are not going to follow the SOLID principles, and they’re not going to be inverting dependencies and writing unit tests either. That’s OK! Other people are not wrong just because I think I can write better code by doing things differently.

It’s not just about code.

Many developers are afraid that software craftsmanship places too much of a focus on writing code. From looking at software craftsmanship from the outside, this is a very valid argument to make. It is, however, mostly based on what is made visible from outside.

The aspects of a software craftsmanship group meeting which people go home and blog about tend to be the katas, exercises, and techniques. Why? Because it is not as easy to bottle up a great blog post on an open discussion among a large group as it is to post about some cool programming exercise. Our community as a whole also tends to really like posts showing source code, so people return from the meeting and post their exercise results. We’re more about thinking and improving our entire development process than just code.

We focus on the micro through programming as well as the macro through community involvement. We focus on how to improve as a business, how to work better with our clients, customers, and peers, and how to do all of this slowly with manageable, incremental change.

What Happens at a Craftsmanship Group?

Our main focus at a software craftsmanship group is to reinforce the skills, beliefs, values, and principles of our members. We have discussions, which are based on topics in the industry. We want everyone thinking, questioning, and improving. We don’t want you to even accept things that other craftsmen tell you. Go to the meeting ready to question others. We need to back up our thoughts and ideas, and most of all we need to be willing to try new things.

Why lightning talks?

Most user groups feature a single person transferring knowledge to the masses who attend the group. In these situations the knowledge flow is unidirectional, and we don’t find that to be as effective as having people of all skill levels discussing the topic. A lightning talk is a great way to introduce a topic by spending 5 to 10 minutes discussing introducing the topic briefly. These talks then open the floor for immediate continued discussion or become ideas for later open discussions at the group.

Why open discussions?

Discussions allow us to share our ideas and get feedback on them. We will often discuss values and principles of craftsmanship. We also use this as a chance to discuss how we’re each solving some similar challenge we’re all facing. Some topics we’ve done in the past revolve around automated unit testing. These often are focused on some type and how to do them better. I recently was involved in a craftsmanship discussion revolving around the concept of BDD and went from low to high level. Some topics deal less with coding than the infrastructure we as developers depend on like our continuous build implementations and our database change management systems. Other common topics deal with how to get buy-in from a business to follow the practices that we believe to be beneficial.

Why code katas?

A kata is designed to give you a consistent experience doing the right things. Like the martial arts equivalent it is not something you would use in a real-world situation, but it is designed to emulate one. It goes through a set of steps where a master of the art has imparted wisdom by showing the steps to be taken when presented with certain challenges. These katas will let you know how and why the master takes certain steps at certain points and are designed to be repeated so that we immediately respond with the correct solution when presented with a certain challenge.

Why programming exercises?

We have all learned to program, and we need to keep ourselves in practice. No, our day jobs are not practice. Exercises are designed to give us practice so that we have recent experience solving challenging problems to assist in our everyday programming tasks. Many people believe that comparing software developers to musicians or athletes is a stretch, and I will agree with them that there are great differences between these groups. We are, however, all skilled individuals and if we’re even remotely similar to the musician or the athlete, then we need to also be practicing.

I’ve been presented with many real-world challenges where I say, “I can use the same technique here that I use when solving the Greed kata.” That being one example of a programming exercise where I have tried solutions and found some that work very well with the practices and techniques that help me write cleaner code.

What should I do next?

Find a local group of software craftsmen. If there is not one in your area or the one in your area is more than an hour drive to get to, then start one. Gauge the interest, and start making noise about it. Other people interested will join the group, share their ideas, experiences, and trials, and keep the group interesting.

Good luck!

The Software Craftsmanship group that I run is located in Hudson, OH. We are between Cleveland and Akron, and we have members from both of those locations. If you're in the area, we look forward to seeing you at one of our events.