Daily Software Development

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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!

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.

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.

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.

I am very grateful to be speaking at my 6th CodeMash. I’ve again been selected to present a precompiler on Software Craftsmanship (a topic I am very passionate about). I hope that everyone can attend my workshops. I’ve got two of them again, so I’ll be spending a full day working with software craftsman coding. We’ll be focusing as always on practicing, pairing, testing, and applying all of these effectively. We’ll work through ways you can use practice to learn new concepts and patterns to improve your skills at building great software.

Once again, Steve Smith and I will be presenting these Precompiler workshops together, so you’re sure to have a blast!

Our sessions are usually held back-to-back, so that you can attend the beginner session in the morning and follow it up with the intermediate session in the afternoon. Last year, our afternoon session had to have extra chairs and tables brought in for all of the extra people who showed up. My goal every year is to put on a workshop that will be the highpoint of your CodeMash! Join us for some great coding, learning, and practicing of your software skills.

If you’re in the Northeast Ohio area and want to learn more about software craftsmanship, you should check out HudsonSC. Our October meeting has been scheduled already. We meet on the third Wednesday of every month in Hudson, Ohio.

I noticed someone recently using a “hard delete” in the git command line recently. I commented on it being brave, but it turns out that he didn’t realize there was a different way to delete a branch in git. In case anyone else is wondering the difference, here is a quick tip on it.

In the git command line, you can use the “-D” parameter to delete a branch. It looks like this:

git branch –D my-branch-name

This will delete the branch regardless of whether it’s been merged back in. This can be dangerous, since you may lose changes that you’ve not yet merged elsewhere.

If you want to be more careful with your branch deletion, you should use a lowercase “d” with the “-d” or “—delete” parameter. That would look like this:

git branch –d my-branch-name

This will delete the branch only if you have merged the branch up already. This means that the branch’s changes should have been saved in the parent branch already, so it’s safe to delete. If you try this when it hasn’t been merged, you’ll received a message telling you that the branch was not deleted for this reason.

If you want to see the branches that still need to have their changes merged, you can do that using the following command:

git branch --no-merged

If you want to see the branches that can safely be deleted, because their changes have already been merged upstream, you can use this command:

git branch --merged

I hope you found these quick tips useful while you’re using git. 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.