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.

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.

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.

Enjoy the rest of July! Don’t forget that you should also be avoiding 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.

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.

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.

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.

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.

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

• Bowling Scoring Kata
• FizzBuzz Kata
• Gilded Rose Refactoring Kata
• Greed Kata
• Potter Kata
• Prime Factors Kata
• Project Euler Problems
• String Calculator Kata
• Supermarket Pricing Kata (Sample Output)
• Tennis Scoring Kata

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

• Ball Flow Recap: CodeMash Coding Dojo
• Software Engineering 101 Cleveland Slides and Demos

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.

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.