Brendan Enrick

Daily Software Development

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!

Parameter and Return Type Interfaces

At some point, I’m sure you’ve had someone suggest that you use an interface instead of a concrete class as a dependency. Assuming you’re following the Interface Segregation Principle, that could be exactly what you want to do. Well written interfaces can make your code much simpler and more clearly define your dependencies. That’s why Interface Segregation Principle is one of those popular SOLID principles you’re always hearing about.

NP-Interface-Segregation

I recently read an interesting tweet from Derik Whittaker talking about using IEnumerable when an ICollection or IList would be the better choice. 

Ugg, may want to fix your code rather than do this "// ReSharper disable once PossibleMultipleEnumeration"

This move toward making everything IEnumerable<T> is a trend happening across the C# community. I believe that ReSharper (a tool I use and love) is leading to some of this. When you write a method that takes in a collection as a parameter, and your method does a foreach over that collection, ReSharper will suggest (correctly) to change it to an IEnumerable. This is because you only enumerated it once, and that means that you can be more relaxed in your requirements.

Side Note: IEnumerable is not technically the requirement for a foreach loop.

The problem people run into with IEnumerables is that they’re not all collections. IEnumerable<T> just means that there is a method to get an Enumerator. In simple terms, I mean that it’s possible to walk through the items in the enumerable one at a time. Sometimes that requires work that’s more than constant time to get to the next item in the enumerable class. The comment that Derik mentioned in his tweet is one that tells ReSharper to not warn you about a possible issue. That issue is that you might be doing the work of walking through the enumerable more than once. When it sees an enumerable that is enumerated for a second time, you’ll receive this warning.

Keep Your Method Parameters Permissive

3364773646_ebc547a3fa_o

When you’re making a method parameter, you want to make sure that you’re only requiring exactly what you need. In doing this, you’ll likely create interfaces following the Interface Segregation Principle. When dealing with collections, you’re likely to accept an IEnumerable<T> if you only enumerate once. You might accept an ICollection<T> if you need to enumerate a couple of times, allow adding and removing, or need to count the items. If your collection needs random, array-like index access, you should consider using IList<T>. 

This allows the caller of your method to give you whatever they have at the time. You really don’t care as long as it has what you need. If their object is an IEnumerable that isn’t also an IList, they can convert it before providing it to you. Working this way makes your API much more flexible, since you’re making your minimum requirements clear.

Return Usable Types From Your Methods

6555544311_79789a44b9_o

Sadly, I see the reverse being pushed as a positive. You will find information telling you to return IEnumerable<T>, so that you can easily change. This, however, means that you’re providing your method’s consumer with no information about the object they’re receiving. If they need access to array-like indexing, they have to call ToList() on your return value in order to use it.

Since ICollection<T> implements IEnumerable<T> and IList<T> implements ICollection<T> and IEnumerable<T>, you can return an IList<T> allowing your method’s caller to use IList<T>, ICollection<T>, or IEnumerable<T> depending on their usage. You’re using an interface and still giving the consumer the power of choice. You can avoid tightly coupling to a concrete implementation while still providing a useful return value.

I almost never return IEnumerable<T>. I don’t know that the return value will only be enumerated once. That’s outside my current layer of abstraction, so I shouldn’t be dealing with it. The safe bet is just to return a useful collection if that’s what I have. If my value really is enumerable, but not a collection, I will return an IEnumerable. In all other cases, it should be a more useful interface. lists an collections really are cohesive concepts that should be grouped into one object when needed.

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!

A Lean Approach to Ordering Office Supplies

I often feel like an arrogant jerk when I walk into nearly any business and my brain starts figuring out ways that things could be improved by applying basic agile/lean principles to some process or another. I think I feel this way, because I’m obviously not the only person thinking here, so there often could be a very good reason for things being the way they are. That doesn’t mean that I’m not going to implement these types of changes within an organization where I work though. Here at Clear Measure’s Ohio office, I did one such thing.

In previous organizations and other companies I know of, there is often a list somewhere of items that need to be purchased. It often looks something like this:

Spiral Shopping List

We often had questions about items that had never been purchased before. We often didn’t know who wrote the request, so there’s no easy way to ask for more input on the item. Additionally, if someone is running to the store, it’s easy to forget the items that are low, but aren’t on the list.

These issues and more are why I’ve moved this whole system into Trello.

Clear Measure Ohio Office Supplies List

What we love about this list is that we have a list of things we’ve ordered before, so that we can check that list for things we’re low on. It’s easy to make the request, and we can update this from our phones, computers, tablets, etc. It also lets you see who created a new card, so you can ask if there’s not enough detail to know what to order. It’s great for another reason for us as well. Many of our items are ordered online from the Austin office, so a physical piece of paper would be a challenge.

For you state or flag enthusiasts out there, that’s the Ohio flag in the background, so it’s really easy to tell that this is the list for the Hudson, Ohio office. Or as I imagine it’s commonly known by our Austin friends, Icicle Central.

Software Craftsmanship at CodeMash Wednesday

If you’re attending CodeMash 2015, you should join me on Wednesday for my precompiler workshop (even if you attended my workshop last year). We’ll be spending the whole day improving our skills, learning about software craftsmanship, and pairing up on programming exercises designed to help you improve the way you learn and practice your coding skills.

If you’ve never attended a software craftsmanship event before, you really should. The entire goal is making sure that you have fun and are able to continue learning more after you leave the event.

For those lucky few of you staying in the Kalahari (still unlikely, since you would have to bribe someone to have even gotten one), I’ve included a set of directions for how to get straight to the Software Craftsmanship Precompiler.

SoftwareCraftsmanshipPrecompilerDirections

If you eat breakfast in the dining hall before the workshop, we’re just outside of there.

What to Bring

Bring a laptop if you have one.

Try to have an IDE to write some code in. Choose a language you’re familiar with or want to become more familiar with. It doesn’t matter!

Make sure that you have a testing framework and test runner of some kind. As long as you can write unit tests with it, you’re good.

If you’re not sure how to get these things set up, show up early and talk with us. We’ll help if we have the time and correct expertise or we’ll find someone who does!

2015 Software Craftsmanship Calendar

People have been asking about the 2015 Software Craftsmanship Calendars. I’ve got good news and bad news for those of you who are looking forward to another software craftsmanship calendar to hang on your walls at work, home, or someone else’s wall.

The Good News

I’ve made significant progress on a calendar, and I’ve got enough concepts, jokes, one-liners written, and sketches for the next two calendars! These next couple of calendars are going to be full of awesome content that you’re all going to love.

The Bad News

Due to circumstances outside of my control, there will not be a 2015 Software Craftsmanship Calendar, so you will all have to wait one year before your replacement calendar is available.

The Future

Please keep the space open on your wall. Steve Smith and I are dedicated to making sure that the next Software Craftsmanship Calendar is better than the previous ones. Follow me and Steve on twitter and pay attention next year for updates about the calendar.

Schedule Standups in the Morning

It may not seem like it’s that big of a deal. I know a lot of people make sure to have a daily standup meeting either with just the team or involving the client. Either way, it’s very important to schedule these meetings in the morning. The reason for the level of importance I place on this is the tone of the meeting.

The most important thing to get out of a standup meeting is having everyone on the same page for what’s going to be done that day. You need to know who’s there, who’s working on what, if priorities are changing. It’s your opportunity to know what is going to happen that day (most likely happen).

If you conduct this meeting in the afternoon or near the end of the day, the tone can shift to discussing what did or didn’t get done. That’s all well and good to know, but it detracts from the discussion of the future. Remember, you only get so much time; use that time to make the next step a better one. Focus on where you’re going, not where you’ve been.

Deleting a Remote Git Branch

Another bit of git command line that a lot of people struggle to remember is the syntax to delete a remote branch. If you read my post from a couple of days ago, I mentioned a couple of things about deleting git branches. That’s how you delete them locally. If you want to push that deletion up to the remote repository as well, you need to take one additional step.

The command I use to delete remote branches is this:

git push origin :my-branch-name

It’s that “:” that tells it to delete the branch. Yes, it may seem confusing, but there is a reason for it. I’ll explain below for those who are interested in learning more.

Here is a slightly easier syntax, but I don’t like typing the additional characters.

git push origin --delete my-branch-name

Feel free to use this syntax, it’s newer, but you most likely have support for it. It’s been out for years now.

Here is the reason (other than its being shorter) that I like the first syntax better.

If you want to push our a git branch, you use this command:

git push origin my-branch-name

If you wanted it to have a different name remotely than it has locally, you would do this:

git push origin my-local-name:my-remote-name

Which means that if you wanted to push “nothing” over the remote branch with that name you would do this:

git push origin :my-remote-name

Notice how the command is pushing empty over that branch, which is then interpreted as a “delete” by git. That’s how I make sense of it, plus this is a neat little bit of info about the command.

I hope this helps people adopt and use git more easily. If you’re new to git or GitHub, I recommend that you check out my Pluralsight course, GitHub for Windows Developers. The course takes an easy-to-follow approach to getting you set up using Git, GitHub, and GitHub for Windows.