Daily Software Development

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.

One of the coolest (and scariest) things I’ve seen lately is mocking static classes and methods with JustMock. I was working on some legacy code, and was making some changes, so I wanted to make sure that I got everything tested first. When I went to write the tests, I noticed that I needed to wrap and hide away a static method that was being called.

My eventual intent, however, is to get rid of the static class and method calls if possible. Writing the wrapper around it temporarily, so I can get tests in place before refactoring has always seemed like a pain. I went to check and see if JustMock would be able to mock a static class. That seemed like one of those crazy things that commercial mocking frameworks can usually do. I was right. It could mock the static class. (SCARY!!)

I wrote some code that looked like this: (Sorry I can’t show you my clients’ code in my blog without their permission, so you get sample code.)

publicstaticclass MyStaticClass

{

publicstaticint DoSomeDependentStuffThatIsHardToFix()

{

// Pretend this does more than just returning 1

return 1;

}

}

In my example, I need to test some code calling this static method. Normally, I would put a wrapper around this class, write my tests, refactor, and eventually change this to not be a static dependency anymore.

I decided to try this. Here is a test class that uses mocking to demonstrate how I can decide any result for this method and have control of this dependency. Notice that my method always returns 1. Pretend that a different result were possible.

Now when I go to write my test, I can just Mock out the static and define that I want that method to be called and for it to return 2 instead of 1. I will then assert that it worked as I expected in my test. Once I confirm that the mock works as expected using this type of test, I can put it in place in my actual test. (Yes, I sometimes write temporary tests to confirm what I expect before I write the whole test. Little steps.)

This month at the Hudson Software Craftsmanship group, we had two interesting discussions that were spawned from the NimblePros Software Craftsmanship Calendar. The calendar’s topic for March 2011 was the Open/Closed Principle and the topic for March 2012 is Reinventing the Wheel. Keep in mind that 2011 is a calendar of good practices we want to encourage and the 2012 calendar is full of anti-patterns to be avoided.

This post is a recap of some of the stuff we discussed at the March, 2012 HudsonSC meeting.

Reinventing the Wheel

Going into the meeting, I had the thought that Reinventing the Wheel is obvious when you’re doing it and Open/Closed is less obvious when you’re not following it. Boy was I wrong. The main discussion we had about Reinventing the Wheel was based on “how do I avoid reinventing the wheel in a large, badly organized code base”. We had a lot of very good ideas and suggestions about how we can try to avoid this through tools, communication, and a variety of other methods and ideas. It’s interesting though, because none of them really are the silver bullet that just solves this challenge. If you don’t know if something is already written in the codebase, it can be a real challenge to find.

Open/Closed Principle

For the open closed principle, we discussed how we use it, when it’s used, and whether we should start of our code building for open/closed. I think most people came to the consensus that it’s likely not a good idea to use Open/Closed right away, but that we should refactor to it when we’re changing the code. The thought here is that if we change it once, we might need to change it again, so the next time we need to extend it instead of changing it.

Make the code better now and we’ll save ourselves time later.

Supermarket Checkout Exercise

As our programming exercise at the end of the day, we decided to do the Supermarket Checkout programming exercise. It is an interesting little challenge that involves some design decisions. This is what makes it interesting.

The exercise has the developers writing a checkout system for a supermarket. Essentially, it’s about calculating the price of the items as their scanned. It factors in discounts, selling by quantity or individually, and selling by weight. This information also needs to be presented to the customer on a receipt at the end of the transaction. This means that you need to figure out how to give the user the needed information in a nice, clean way.

As you work on the code, you have to make some decisions on how the code is going to interact with the customer. Should the discounts appear inline immediately or at the end? Is the discount a separate line item or shown in the price? How do these choices affect how you’re writing the code? Some have you returning information immediately and some have you gathering the information later. How do you adjust your design decisions based on this?

You can find a link to this programming exercise and more on my List of Katas and Programming Exercises. And, because I am not a total jerk, I will give you a direct link to the kata pdf in case you don’t want to check out my other blog post.

The Sample Output is optional to use. You can also come up with any sample output that you wish to use for it. Change things up. Or do the kata and then pretend that the business rules have changed and now you need to display the information differently.

I believe there are two main types of “teams”: those working together, focusing on doing their best as a team and those working individually, focusing on doing their best on their own. (Yes, some teams are in between.)

I think you can guess based on my wording of those two options, that I prefer working as a team toward a combined goal. By working together, we can accomplish much more. We must be careful along the way, however, to make sure that we don’t do anything that can hurt the teams abilities to work as a team.

Building a good, cohesive team is my greatest achievement in my software development career. Being a part of this team as it achieves great things is what I have received in return. – Brendan Enrick (March, 19, 2012)

I am always trying to make sure that the team is doing well. I try to keep them focused and working together. Most of all, I try to make sure that the things I do don’t hurt the team. It’s important to recognize that decisions and choices we make affect the team a great deal.

Building strong teams requires a lot of work. This post focuses on considerations that I believe are important to creating strong teams. These considerations include: communication, co-location, combined interest, respect, and commitment consensus. I focus on these when trying to create good, cohesive teams.

Communication

Creating great software depends heavily on communication. This is important for the whole team. It’s important that all members of the team be communicating with all other members of the team. If communication breaks down, the team is soon to follow.

It’s important for the whole team to be talking, writing, documenting, and sharing their ideas. Make sure that your team feels safe working together and communicating with each other.

Communication is so obvious as an important aspect of a good team, that I am not going to spend a great deal of time discussing it.

Co-location

There is no easier way of getting a team to work together than to have them located together. Keeping the team close together keeps communication high. Not only does this mean that asked questions will be answered quickly, it also means that questions will be asked. If the team were not together, someone might not have asked the question. This keeps the communication barrier low and the feedback loop short.

I said this was an easy thing to achieve, and it can be. Sometimes there are difficulties with logistics of your space, people not wanting to move, etc. These can happen and can also be worked through. If you don’t have a team room, you can still set up a “command center” in an unused conference room.

I’ve seen both introverts and extroverts do well in co-located teams. When the conversation is on-topic it allows everyone to tune in to what the team is doing. The team will start answering questions immediately, knowing what everyone else is working on, chiming in with assistance on an area of expertise.

Combined Interests and Goals

It’s extremely important that a team have a shared goal. If you fragment the goals of your “team”, you will be fragmenting the “team”. You run the risk that the team will have no incentive to work together. Yes, you might say that since everyone gets along, they’ll work together still, but you’re driving in a wedge that will pull them apart.

I don’t want my team to have individual goals, this will cause them to work on their own and make it harder for them to work together. Anyone spending their time helping someone else would be in danger of not finishing their own work, but I want them working together to achieve more.

Nothing is as detrimental to a team than making them behave less like a team.

By combining the goals and interests of the team, you force them to work together. They get the idea that they’re being graded together and being rewarded together. This will keep everyone on the team at their most productive, because they will all have each other to lean on.

Respect

This word gets four uses here. It is important that members of a team treat each other with respect, it is important that members of a team respect each other, it is important that each member respects oneself, and it is important that everyone respect the code being written.

If one member of the team doesn’t respect another of the team members, the team will not be cohesive. If one member of the team doesn’t show respect to one or more members of the team, the team will not be cohesive.

If one member of the team doesn’t respect oneself, the team will not be cohesive. If one member of the team doesn’t respect the code being written, the team will not be cohesive.

When the team has respect for each other, they will strive to not hinder the rest of the team. This means that they will try not to break the code base. They will try to make sure that they build good, simple designs that everyone can appreciate. And communication will also flourish.

When the team has respect for themselves and the code they’re writing, they will strive to write clean, simple, well-tested code. The team will care about the work they’re doing and will avoid creating a big messy codebase.

Commitment Consensus

Making any commitment as a team must be done with a consensus among the group. One of the worst things that can be done to a team is to set their commitments for them. You can’t tell someone else what they are required to commit to.

Commitments have to be made willingly or the commitment might as well not be made at all.

This mistake is commonly made by people assigning work for the team to work on without getting their feedback on it. If you assume that a team can get X amount of work done without asking them, you’re asking for trouble. First, you’re making their decisions for them. This is going to make you into the opposition of the team. Second, you’re not soliciting their opinions or feedback.

Often this means that someone who is not going to be doing the work has estimated the time the work will take to complete and has assigned this work to individual team members. This will break the combined interest, encourage the team to break from their co-location, and cause the team to feel the person making those decisions isn’t taking them into consideration.

The right way is to work with the team. If you do need a commitment on something, you should work with the team to create that commitment. This usually means sitting down and working with them on it. Get them to decide what they can accomplish in an amount of time. Work with them to decide what will be worked on. This means that the person deciding the direction of the project should be directly talking with the development team doing the work.

Getting people together, working together, collaborating, is what makes teams effective. Don’t try to force them into doing something they don’t want to do. It will backfire on you. Plus, they’re likely not going to uphold that commitment. It wasn’t their commitment anyway. Not really.

The Team

If you manage to get the team working together effectively, keep it up. Try new things, but don’t let it destroy the team. If it looks like it’s hampering the team’s togetherness, quit doing it. Find another way of doing whatever you’re doing.

Don’t force the team into processes they don’t like. Let them create a process that works for them. Give them the tools and enable the team to make the right choices. Empower your team! Make sure that you never become the opposition of the team. Try to be part of the team. Align your interests with theirs.

Recap Posts About Katas, Exercises, and Games

So as a bit of fun, since I just wrote a post about duck typing and foreach loops, I thought I would take a look at what’s happening under the hood when we use this trick. To start with, I will have two classes, which each have GetEnumerator methods. The first one is using DuckTyping, so it doesn’t implement any interfaces. The second one is implementing the IEnumerable interface. Finally, I have a third class with a method that just uses a foreach loop over instances of the other two classes.

Yes, it’s a bit ugly, but you will notice that other than naming, the code is just repeated twice. This is of course what we would expect, since the code should treat it the same regardless. All the foreach loop needed was to be able to get the object from the GetEnumerator method. Once it has that, it just uses the enumerator to do all of the work. This means that either class should work just as well.

This is the repeated line of code that shows up in two places to get the enumerator it will be using for its MoveNext() and GetCurrent() methods.

Now if you’re really paying attention, you will have looked at the Try-Finally block that is in the code to handle our IDisposables. That’s another neat thing happening behind the scenes, but that’s another blog post entirely.

The coding dojo at CodeMash 2012 was a blast this year. I ran two events in the dojo: a group exercise doing the Gilded Rose kata and the Ball Flow agile game. I thought the gilded rose kata we did as a group exercise was a great success. We had a good group of people, which was impressive considering that even with floor decals, people had trouble finding the coding dojo.

The coding dojo at codemash is a great place for actually doing things at CodeMash. If you’re tired of sitting there having someone talk at you, head to the coding dojo. It’s a place for writing code, learning, experimenting, and having a great time. We did katas, programming exercises, and some educational games in the dojo this year. If you did not make it to the dojo this year, we hope to see you next year!

Ball Flow

The Ball Flow game is an Agile exercise where a team of people work together in an experiment in self organization. The team will do some estimation, some planning, some retrospectives, and they will be trying to continually improve their process while aspects outside of their control continue to change. The team has to adapt and figure out how to keep working together effectively.

Object of the game:

Pass each of the 20 balls to each person in the group.

Rules of the game:

A person may touch a ball more than once, but doing so isn’t ideal.

Two people may not be touching the ball at the same time.

You may not pass the ball to your nearest two neighbors

If the ball touches walls (including floor and ceiling) or any furniture it must start over.

The person who first picks up the ball must be the last to touch the ball.

What this group did

Our group started out by figuring that if they created an oblong shape, they could pass across pretty easily. They got in this shape and began passing around. They had two tall people stand back a step so that they could launch the ball over everyone else across the group. Their final pass went behind the backs of one side of the group back to the starting person who removed the ball from the game.

They spent some time planning and adjusting between each iteration. They made sure not to make big changes fearing the catastrophe that could occur. Each time they made modest improvements to their time.

As the game went on we added challenges, in one round we added a large number of pens that needed to be passed around as well.

In the final round we added in bags of potato chips, which were harder to throw across the room. Each time the group still managed to make slight adjustments to accommodate these changes and still slightly improve their times.

During my Software Craftsmanship Precompiler session, I heard one of the students say, “all you need is an IEnumerable to use a foreach loop”. This sparked a bit of fun when I asked Steve Smith, my co-presenter, if that was correct. He confirmed that it was, and I disagreed. Being the scientists that we are, we decided to try it and see what happened. I of course knew that duck typing in C# should allow the Foreach loop to compile without anything having the method required by the IEnumerable interface. This means that we just need a GetEnumerator method.

We wrote the code that did this and it compiled!

Duck typing is awesome, because it allows the language to treat my type the way I want it to because it has the right tools to do the job. The term duck typing comes from the idea that if it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

In the foreach loop example, duck typing assumes that what you have here is able to be enumerated, because it has a method to get the enumerator. If we look at the IEnumerable interface, we can see that this is what we are required to implement.

Now that CodeMash is over, it’s about time that I deposited information about my experiences at CodeMash 2012 here.

This was my third time at this event that always offers great sessions, workshops, discussions, fun, and bacon.

I am honored to have again been given the chance to speak at CodeMash. I co-presented the Software Craftsmanship precompiler workshops with Steve Smith for the 3rd year running. This year, we broke our day-long workshop into 2 sections: one beginner session and one intermediate session.

Both sessions turned out really well. We had a lot of good verbal feedback from the attendees during the workshops, we had some of our morning people stick around for the afternoon, and I heard from other people that those who attended enjoyed the workshop. I am really happy with how well it turned out. Thanks everyone who attended the sessions.

Beginning Software Craftsmanship

In the morning we did a beginner’s workshop that introduced the idea of Software Craftsmanship and what values go along with it. We discussed what people can do to get involved with their communities and realign their focus on building good, high quality software. As part of this, we show the group how they can work on improving their skills as Software Craftsmen through Katas and other programming exercises.

We had between 30 and 40 people attend the morning, beginner workshop, including a cobol programmer. We had the attendees mostly working on the Prime Factors Kata through the day. We started them doing the kata with little direction and asked that they do the work solo and without testing. We then had them do the kata again, but this time use testing to keep them on track designing their applications in a simpler way. In the third time doing the kata, we had everyone work in pairs on the kata to see how far they could get as a team using TDD.

Our main goal with the programming exercises in the morning is to have everyone leave with an understanding of pair programming, TDD, how to use programming exercises to hone their development skills, and we wanted them to leave motivated to work with their local communities to all become better at creating quality software. I believe we succeeded in our endeavor. The students talked about how the testing made the work easier and that pair programming was also much easier.

Intermediate Software Craftsmanship

The afternoon focused on some of the same ideas as the morning, but the people in the afternoon know about the values of software craftsmanship. We briefly reminded everyone, as I believe should be done. It’s important to remember and discuss why we do what we do. It gives us a chance to remember and reconsider everything we know and believe.

For this workshop, we had more than 50 people show up for the workshop, which meant that some people did not have table space for their laptops.

In the afternoon we did a few different exercises. One of them focusing on green-field development using good design patterns and practices to help reinforce how to use these effectively. The Greed kata is a great place to try out the strategy pattern as well as a few other good patterns. In the exercise, you continue to get more and more scoring rules added. Eventually, you want to get to following the Open/Closed Principle so that you’re not changing the existing code each time.

The other exercise we did is one which starts out with existing code to refactor. In the refactoring exercise we ask you to add a new feature. It then becomes your choice how to do it. You could just hack in an “if” statement. You could also take some time and refactor. Before you refactor, however, it’s usually a good idea to try to get some tests in place. To make things even more like real code, you need to perform a couple of careful refactorings before you can put your first tests in place. You also get to decide how many tests you want to write and how much to refactor when adding this new feature.

Future Events

If you want to take part in this or a future workshop, I am hoping that CodeMash will invite me back next year to do another great workshop or two. I am also hoping to do a free Software Engineering 101 event again in Cleveland.

In software development, it is very important to continually learn and experiment with new techniques for building great software. Our job is to learn and improve the quality of code that we build over time. It is through this progression of experimentation, failing, succeeding, observing, reading, listening, and teaching that we as developers improve. In this post, I am going to discuss one way in which we as developers have learned something great and have taken it to the point of failure. This will allow us to learn, resolve, create new techniques, and succeed in the future.

What is Dependency Inversion?

One of the most important SOLID principles for testing our applications is the Dependency Inversion principle. I am very glad to see many more codebases using this technique as time goes on, however, I am seeing nearly as many others getting caught up in an easy mistake of using too much injection and putting interfaces on everything regardless of necessity. Lets start by defining dependency inversion so we’re all on the same page.

From Wikipedia:

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. The principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

Reading directly from this, we can see that it says we should be depending on abstractions and in doing so we take a much lighter dependency. A dependency on an abstraction is not a big deal. A dependency on a concrete class is a big deal.

Is what I just said always true? No, it depends on the abstraction and the concrete class. For example, I make an exception for simple classes provided through the framework or language my code is primarily based on. For instance, I have no problem saying that my method depends on being given a DateTime object since there is no real gain by abstracting that object since that is a part of the framework and I will always be injecting in an object of that type.

When are interfaces and injection being overused?

One example of over-architected injection that I see a lot comes from something that I’ve taught many times when explaining SOLID. It’s the classic example of a dependency that people don’t realize they have.

DateTime.Today

I assume most of my readers know that this is a dependency taken directly on the system clock. It’s important to inject this dependency when your code behaves differently based on the value returned from that static method. When we extract that dependency, people have been taught (by many people including me) that a good way of testing this is to have some kind of IClock interface with an implementation of SystemClock accessing the computers clock by calling that static method we were just discussing.

Now when we write our method, we just give it a parameter of IClock. When we run our code in production, it’s taking in the SystemClock object, and in our tests we’re using a mock object. Great! We’ve reversed the dependency! Is that really what we wanted though? It might have been, but in some cases we could have just passed in the DateTime instance object returned from that method. This would have reduced complexity in our code.

Because we used this interface instead of just depending on simple concrete classes, we’ve actually made our code more difficult to use and maintain. Isn’t that the whole reason we were following SOLID in the first place? Yes, yes it is. This is of course a simple example, but you can find larger examples of where you could test your code and build in a nice structure without having to create pointless interfaces. Heck even in this example, you might have a good reason to need that Interface, but I am sure that you could get away with using it less. Every time you add that layer, you add complexity. Sometimes adding it is OK, because it gives you a much needed seam, but I doubt you need it as often as you think.

Please make sure that you need the interfaces and layers of abstraction before creating them. I’ve come across many codebases that become as complex or more simply by trying to do things “the right way”.

The road to software development hell is paved with good intentions.

Don’t like the way I phrased something? Think I overgeneralized? Did I make a mistake?