Brendan Enrick

Daily Software Development

2017 Software Craftsmanship Calendar

After creating software craftsmanship calendars for four years, we (the software craftsmanship calendar team) took one year off. All we heard through December of 2014 and January of 2015 was people asking us how to get their 2015 calendar! Well, there wasn’t one! Unfortunately, none of us worked together anymore, so making the calendar became quite the challenge. There was no longer an employer backing all of us and fronting the bill for design costs and printing costs.

We found our solution to the problem though, we set up a Kickstarter to fund the initial costs of the 2016 calendar, and with the support of all of the backers of that campaign, we were able to create the 2016 software craftsmanship calendar.

What are these calendars?

The Software Craftsmanship Calendars use the motivational poster-style formatting with an image of a humorous real-world interpretation of a concept related to software development. These images and jokes throughout the calendar acts as entertaining reminders of the standards we all want to hold ourselves to.

Software Craftsmanship Motivational Images

With the 4th and 5th calendars, we discussed the idea of doing a “Greatest Hits” calendar where we would mostly use our best ideas from previous calendars. Some we would reshoot the pictures, others might get touched up, and a few images would be new. This would make the it one of the best calendars we could make, since it was using our previous, great ideas! With five calendars under our belts, we’ve decided it’s time to do just that. We’ve got loads of previous images and ideas to choose from.

2017 Kickstarter

We’ve set up another Kickstarter. This time, for the 2017 Software Craftsmanship calendar.

Stretch Goals

We want most of the images in this calendar to be the best images from previous years, so that this calendar can be our best one yet. We are willing to take some chances by adding a couple of new ideas and images, so we’re setting those up as stretch goals this year.

Stretch Goals

Please go back our Software Craftsmanship 2017 Calendar Kickstarter, and get yourself or your team some calendars to remind you how you want to be building software. Or if you like, pick some up for those people who could really use the reminding.

Making The Software Craftsmanship Calendar Images

In case you missed it, Steve Smith, Michelle Smith, and I are Kickstarting the 2016 Software Craftsmanship Calendar. Make sure to support and share the project so that this awesome calendar can make a comeback! We are dedicated to making this happen, but need your support.

This will be our fifth calendar, so we’ve got a lot of practice. None of us work together anymore, so we didn’t have a company backing the 2015 calendar. As a result, it didn’t happen. We’re going to fix that for all of the people who were contacting us and others related to the calendar trying to get their 2015 editions; the 2016 calendar is for all of you. I know it’s really early to be thinking about buying a new calendar, but there a printing deadlines, so we really do make these calendars in the summer. As a result of our efforts, those of you who were lucky enough to have the 2012 or 2014 editions of the Software Craftsmanship calendar got to have a picture of me up on your wall for an entire month for each of those two years! I have no idea if I’ll make it into the 2016 calendar, but it will see be awesome. Here are the pictures I was in!

Death March

Death-March-Me

Mushroom Management

Mushroom-Management-Me

In the spirit of explaining what goes into making each of these calendar images, I’ve decided to write a post here showing how the Mushroom Management photo got the way it is.

Step 1 – A Principle or Anti-Principle

We always start with some principle that we want to make. There are so many to choose from that we have to trim the list down to any we can get an idea for. That means that we start by brainstorming ideas, and keep the principles that we got any ideas for. It doesn’t matter how good the idea is. If we could come up with a visual we keep it and continue working on the visual. We have this set of criteria for the visuals:

  • The image has to relate to the principle.
  • The image has to be interesting enough to have on a wall for a month.
  • The image should have a humorous aspect to it.

Step 2 – Sketch the Idea to Make Sure It Works

Before we make any props, find a location, and start taking pictures, we have to make sure the idea will actually work. We also want to know what we need to set up. Not all ideas require this, but it helps choose between multiple ideas. It’s also a great point to iterate on before we start shooting. Often the sketches only resemble the image, which is why we spiked the idea with a sketch first.

Mushroom Management Sketches

MM-Concept-1

MM-Concept-2

Golden Hammer 2.0 Sketches

CalendarConcept19

CalendarConcept18

Frankencode Sketch

CalendarConcept21

Step 3 – Make Any Required Props

The golden hammers we’ve used over the years were all made by us. We’ve made 4 different hammers over the years. Only two of them made it into calendar images. Two hammers were real hammers that we painted gold. One was a plastic hammer painted gold. The one featured in the 2014 calendar that looked like something Thor might wield was custom made by our designer Weston. He sculpted it, painted it, and even cut and wrapped the leather for the hilt.

The Original Hammer

Golden-Hammer

The Thor Hammer

Golden-Thor-Hammer

And this is how the hammer was made:

DSC_0504 

DSC_0514

Step 4 – Start  Photographing

Perhaps the most obvious part of the process, we do have to take some pictures. We make sure to take quite a few pictures (including some making of pictures to go in the back of the calendar). For the Mushroom Management photos, we did a photo shoot, and the photos were not quite right. We knew we needed to make some changes Take a look:

DSC_1125

We really thought that the team needed to look like they’d been sitting in that room for weeks, so we did some thrift store shopping and obtained some visually “interesting” shirts for the team to wear. We also wanted to Mushroom Manager to look a little more formal. We shot again the next day. That got us here:

MM-Untouched 

Step 5 – Touching Up Some Lines

And to make things look amazing, our designer takes these images and makes them complete. OK, so it’s a bit more than just a few lines, but the work he does is fantastic. We’ve gone from an empty office to a development dungeon.

MM

Step 6 – Choosing Behind the Scenes Photos

Our developers in that pictures are in fact developers, not actors. They’re actually pretty uncomfortable in that room. They’re sitting on the floor, closed in a room, with the air conditioning off in the August heat. Being the mushroom manager, I’m supposed to be comfortable, so I’m making sure to stay cool. That’s why I made sure to wear the lightest pair of shorts I owned for this shot.

MM-Brendan-Hallway

That’s how you really class-up an outfit right there. worn athletic shoes and blue shorts go really well with a sport coat, shirt, and tie. Trust me!

Step 7 – Enjoying the Calendar

Yes, this is our favorite part as well. When we get to see our first, fully printed calendar. It’s amazing to see thousands of hours of work come to life in the form of a calendar. Yes, we know the number of hours that go into these. NimblePros was in the software consulting business, so we tracked the hours we billed toward our internal projects like these.

Help us make the 2016 Software Craftsmanship calendar, so you can also enjoy smiling, laughing, and being reminded of all of the ways that you can fail at making software or working as a team!

Don’t Repeat Yourself with Copy Paste Programming

If you’ve kept up with your Software Craftsmanship Calendars, you may have noticed many of our little jokes that were not even the pictures in the calendars. One of my favorites is that we violated Don’t Repeat Yourself and followed “Copy Paste Programming” in the 2013 Software Craftsmanship Calendar.

In the 2011 Software Craftsmanship Calendar, we did a set of principles that you want to follow with humorous pictures of them not being followed. In that calendar, you would have seen the Don’t Repeat Yourself (DRY) Principle.

DontRepeatYourself2011

Then in 2012, our anti-patterns calendar, we did Copy Paste Programming. In that picture, someone needs a bunch of different paintings with individual requirements, so they started with one and copied, pasted, and adjusted each.

NPCopyPasteProgramming

Then in 2013, our calendar was again about principles, so we followed Copy Paste Programming and violated Don’t Repeat Yourself by including Don’t Repeat Yourself again! We made one slight adjustment.

DontRepeatYourself

Did you notice that the apple is green now? Quite the change, eh? Totally different. Definitely not a repeat.

If you liked these and want to help us create more calendars like this, you should support our Kickstarter for the 2016 Software Craftsmanship Calendar!

SOLID Principles – Software Craftsmanship Calendar Topics

The SOLID Principles are a set of Object Oriented Design Principles that are very interrelated and when followed can improve your code. Additionally, they make a great acronym that implies the benefits of using the principles. In 2011, at NimblePros, we made a calendar of Software Craftsmanship Principles and made humorous images to go along with them. We continued making the calendar for three more years and then missed 2015. Now we’re making a software craftsmanship calendar for 2016. Please back the calendar on Kickstarter, so there will be a 2016 edition.

Single Responsibility Principle

While it might seem useful at the time to just keep this stuff together, you may eventually realize it isn’t.

SingleResponsibilityPrinciple

Avoid tightly coupling your tools together.

Open Closed Principle

It’s important that your code be open to extension while being closed to modification. This means that you should be able to add additional functionality without significantly altering the existing functionality. Remember the dangers of changing code; bugs can easily be created.

OpenClosedPrinciple

Brain surgery is not necessary when putting on a hat.

Liskov Substitution Principle

Any class implementing an interface needs to be substitutable for that interface. For example, you can’t have missing functionality when implementing your interface, or it’s not really substitutable. Developers shouldn’t need to be careful about using a specific implementation of an interface. That was the point of using an interface.

LiskovSubstitutionPrinciple 

If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction.

Interface Segregation Principle

Your interface should match only the needs of its users. If you pile on too many features to your interface, you make it hard to implement and difficult to use. The implementations are also likely violating the Single Responsibility Principle just to implement your interface.

NP-Interface-Segregation

Tailor interfaces to individual client’s needs.

Dependency Inversion Principle

Don’t get too specific on your dependencies. Make sure that you’re depending on something stable. This is often some kind of an interface. In our example below, an outlet and a plug make the connection nicely. You don’t want to hard-code specifically to the connection you have; you might need to change your connection at some point.

NP-Dependency-Inversion

Would you solder a lamp directly to the electrical wiring in a wall?

I hope you enjoyed these SOLID principle pictures. And if you want to see more of this kind of humorous take on important software development principles and ideas, back our Software Craftsmanship Calendar 2016 on Kickstarter.

2016 Software Craftsmanship Calendar

At then end of 2014, I wrote an article about the 2015 Software Craftsmanship Calendar that we were not able to make. The best news I have for you is that we’re doing a Software Craftsmanship Calendar for 2016, but we want to make sure that we are able to cover the costs of making the artwork and printing the calendars. The cost per calendar comes down as we print more, so we’re doing a Kickstarter for the 2016 calendar to make sure that we don’t take a big loss by printing the calendars.

Previous Calendar Topics

I’ve written articles about topics from previous years. You can read about those and see the pictures below.

Go back the 2016 Software Craftsmanship Kickstarter and get a calendar for yourself and some for other developers who need them!

Flags Over Objects

If you didn’t notice it, our “flag” month was the same month as Independence Day in the United States. We celebrate that day with flags, fireworks, and a lot of cookouts. Notice anything in the picture? Yep. We’re missing the fireworks. Anyway, the topic of Flags Over Objects is an important one.

Flags Over Objects is the Software Craftsmanship Calendar’s anti-pattern topic in July 2014. As a developer, I am sure that you’ve come across code where boolean values (flags) were used far too much. This is often a misuse of state. Plenty of times there is a better, simpler way of handling the state of objects.

Flags_Over_Objects_July_2014

In this image, you might notice (looking carefully) a few obvious (and common) issues with using flags. First, you’ve got a whole list of checkboxes even though some of those can only ever be one at a time. You might also notice that there are a lot of repeats of the same checkbox.

Are you using this anti-pattern anywhere?

Assumption Driven Coding

As software developers, we have to make a lot of assumptions about things. It goes with the territory, however, we try to avoid making assumptions whenever we can. One of the values that we hold up is Communication, and that means that we need to communicate with our users. June 2014 is Assumption Driven Coding month according to the 2014 Software Craftsmanship Calendar Anti-Patterns edition.

The calendar (as always) takes a more visual approach to this software development issue.

Assumption_Driven_Programming_Jun_2014

Obviously, we’re supposed to notice that Eric is missing a hand, so he cannot use this newly installed palm scanner. Whoever decided to put in this new interface should have thought of a backup system for Eric or used a different authorization mechanism.

If we step back and think of this in terms of software, we’re talking about making an assumption about our users, data, or how interaction with the system will happen. An example of this would be assuming that your users “all use the start menu”, “all search for programs”, “all use the quick launch bar”, or “all use the desktop”. Each of those is an assumption that Microsoft could make when developing its next version of Windows. Each of those assumptions would be a bad one. Heck, even assuming that I named all of the possibilities already is a really bad assumption. What if someone uses “Run” or PowerShell?

When we’re writing our software, we take a lot of guesses about how the users will use our systems. Don’t! As you’re building, watch them use it. See how they use the system. Ask the user to perform their daily routine in the new software and see what they do. Ask them some questions. And make sure that you check different types of users. Sure, you will not catch every case, but you can avoid a lot of headaches. You might not even have realized that certain users would use the feature you’re building if you don’t ask.

Let’s focus on avoiding this issue for the rest of June.

SPOILER ALERT: Eric has both a right hand and a left hand… This photo is fake.

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!

Calendar Coder

If you didn’t get yourself a 2012 Software Craftsmanship Calendar, I hope you’ve at least been following along with my blog posts. My favorite of the months is finally here. In the 2012 Software Craftsmanship Calendar, we included our own variation on an anti-pattern. December is Calendar Coder month.

CalendarCoderSmall

Jesse Williamson had a spectacular tweet that confirmed exactly what we were looking for when we came up with this idea.

Just got trolled by my 2012 Software Craftsmanship calendar. Well played, inanimate object, well played.

Yes, that’s right. After you’ve followed along with the calendar all year, accepting guidance as the calendar turns anti-patterns into jokes that make you rethink some bad practices, the calendar turns on you. I really think that the calendar is useful, but there is no substitute for thinking. Make sure that what the calendar says makes sense. Blindly following everything the calendar says to do is just silly.

Do you recognize from which anti-pattern we derived this one?

It’s called by many names: cargo cult, angry monkeys, etc. If you’ve ever heard the story about needing to cut the ham in half before you bake it, that’s the same story. It is the practice of following along without knowing why you’re doing something. If you read the calendar and don’t know why you should do what it says, you’re a Calendar Coder. If you learn why, agree with the reasoning, and it’s applicable to your situation, then you will want to follow what the calendar says. Don’t just blindly follow along though.

I hope everyone enjoyed the calendar. If you did, the new ones for 2013 are on sale right now.

Buy your 2013 Software Craftsmanship Calendar today!

Copy Paste Programming

One of the most well known anti-patterns is copy paste programming. I am sure that every programmer has done some copying and pasting of code. It’s easy to do and can make writing code a lot faster than just writing new lines for everything.

You might have done something very similar to what you need now. All you have to do is copy the previous code and update it to fit your current needs. What could possibly go wrong?

I don’t think I need to explain why this one is bad. I think it’s easiest to just say that more code means more maintenance. It makes things messier, harder to read, and harder to change.

The month of September 2012 is the Copy Paste Programming month in the NimblePros Software Craftsmanship calendar, so consider this your reminder to stop copying and pasting code. You should know better already.

CopyPasteProgramming

I loved how well this image turned out. I’m sorry though, it’s not OK to copy and paste your code. No, it doesn’t matter that you’re making slight changes each time you copy it. Just don’t.