Category Archives: Software Craftsmanship

SOLID Design Principles at Launch Academy

I had an awesome day speaking to the students at Launch Academy in Boston.  I have a lot of respect for what Dan Pickett and Evan Charles are doing over there, and I hope it brings a lot of new, great developers into the community.

I had initially planned on doing a talk on the SOLID design principles, but as the group is just starting out learning good practices, I didn’t want to throw too much at them at once, so we focused on Single Responsibility Principle, Dependency Inversion Principle, and an Agile design practice called Incremental Design.

It was a ton of fun.  They are such an energetic and engaged group.  They had very good questions about technical debt, what constitutes a good test suite, and resources for further learning on TDD.

The talk is available below, although due to some technical difficulties at the talk I had to re-record it, so I didn’t get their questions or the wild applause at the end 😉

Thank you Launchers for hosting me, and I look forward to seeing more of you in the Boston developer community.

The example code used in the talk is available here

Here are the references from my talk

Bob Martin (Uncle Bob) on SOLID
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Sandi Metz – SOLID Talk at GORUCO
http://www.confreaks.com/videos/240-goruco2009-solid-object-oriented-design

Derick Bailey – Los Techies
http://lostechies.com/derickbailey/2011/09/22/dependency-injection-is-not-the-same-as-the-dependency-inversion-principle/

James Shore – Art of Agile
http://www.jamesshore.com/Agile-Book/incremental_design.html

And lastly, here are the slides

Advertisements

Craftsmanship and When Not To Refactor

I love learning how to write better software.  That was the attraction for me to the Software Craftsmanship movement.  Here is a group of folks that are concerned about developing  software in a way that is extensible, testable, and maintainable.  I have learned so much about techniques like SOLID, different pair-programming strategies, TDD, DRY, and the list goes on and on and on.

But let’s not lose sight of our jobs here.  We are paid to develop features that our customers need.  Our customers are not going to care how the software is crafted under the covers, unless it gets in the way of us being able to add new features, extend existing ones, or provide a reliable platform.

We have an awesome team room where I am working, with all kinds of information radiators that help us do our jobs and communicate to our customers how we are doing.  We keep our retrospective goals on 3×5 cards in a visible place so they stay fresh in our minds.  Lately, as a result of some pain we felt adding new features, we have been pushing hard to refactor code that gets in our way or makes it difficult to extend the software.

Here are what two of the cards remind us about our refactoring practices:

Refactor all the time as you go.

This encourages us to keep the code clean while we are developing in, remembering the “refactor” in the “red-green-refactor” loop and avoiding the “red-green-red-green-red-green-refactor-refactor-refactor-refactor-refactor-refactor” anti-practice.

If any code is slowing you down, change it (in small slices)

This drives us to fix code that is making it difficult to maintain or extend the code.

There is no card though that says “If you see something you don’t like, change it”, and I think this is where you can get in trouble with the notion of “merciless refactoring“.

We’ve all written code we don’t like or would write differently knowing what we know now as opposed to last year, last month, or even last week.  But that is not carte blanche to re-write something just because it comes into our eye-line.  If it gets in our way, that’s a different story, but we need to keep our eyes on the prize and that prize is the new feature that we promised our customer at the end of the iteration.

Anyway, that’s my two cents.  This soap-box I am standing on is starting to creak, so I better get down now.  Please feel free to share your thoughts or observations.

P.S. In thinking about this I saw some good posts on the subject that you may find interesting:

http://devblog.avdi.org/2012/06/25/every-day-in-every-way/

http://dannorth.net/2011/01/11/programming-is-not-a-craft/

Why Katas

The Merriam-Webster dictionary provides the following definition for kata

Kata

a set combination of positions and movements (as in karate) performed as an exercise

Most people are probably familiar with katas as they are used in martial arts (come on, admit it, you liked the Karate Kid).  My introduction to katas in software was through the Software Craftsmanship movement, where they are often used as training exercises.

It is important to understand with coding katas that the idea is not to do the exercises the same way every time.  Katas are a great way to experiment with different techniques and styles.

  • Can I provide more descriptive naming
  • Does a terse syntax make the code easier or harder to understand in a particular place.  Would a more verbose, explicit approach be better.  For example, in the case of a complex ternary operator, would an explicit structured if/else construct be better?  Worse?  Try them out and decide for yourself.
  • Experiment with different syntax, e.g. the unless keyword in Ruby.  More or less readable?
  • Should I use a defensive programming style checking for nil/null in several places or a more confident programming style?
  • How am I naming my tests (yes you should be writing tests as part of your katas)

There are no right or wrong answers to these questions, the goal is to experiment and try out new ideas.  Understand where an idea works well and where it doesn’t work well.  Try a variety of approaches.  And the great thing about a kata, unlike your code base at your real job, is that you can blow it away when you are done and do it a little different the next time.

Katas and Interviews

I’ve been using pairing as a key part of the interview process for several years now, but a consistent challenge is to what to pair on.  It is unrealistic to assume that most developers are going to walk in the door and instantly grok your code base.  No matter how awesome you are or how descriptive the tests are, it’s just not gonna happen. Instead pick a problem set that a candidate can quickly get their head around and that you can discuss different design and implementation choices.

Katas and Pairing

I had an awesome pairing session yesterday with someone I had never worked with before, and we did some katas as a way to get to know one another, discuss approaches to coding, good naming, refactoring techniques.  It was a blast!

And the really great thing about katas and pairing is that it can be challenging to think of different ways to try something on your own.  But with a pair you have different perspectives baked-in.  And what you can learn may not be strictly code related: it could be keyboard shortcuts, different IDEs or editors, maybe even a wacky keyboard.  Don’t be afraid to experiment.

Resources for Katas

Cyber Dojo
Great resource for ideas for simple exercises.  Even if you don’t use the online collaboration tools, it has a great list of problems that can be used for a kata.  I used this yesterday for my leap year kata in Ruby

Dave Thomas’s Katas
This is the blog post that kicked off a lot of the talk about katas in the software craftsmanship movement. Again, great problem sets that you can get your head around quickly, but with enough meat for some interesting challenges to address.

Your Friendly Neighborhood Software Craftsmanship Group
Here in Boston we have Boston Software Craftsmanship. Great group, someone’s always willing to pair.  Find your local group, or start one yourself.

Another Developer on Your Team
Ask someone on your team if they’d be interested in brown bagging it some day and do some kata’s together.  You should do this especially if you are not pairing now or are not doing TDD.  You may find that you should really be pairing and you really should be doing TDD.  You should.  Really.

CodeRetreat.org
I had a great time at last year’s Global Day of Code Retreat.  Check it out.  Conway’s Game of Life is a great coding exercise.  This also introduces some great constraints and pairing ideas that really get you thinking.

Now get out there and start coding…

On Fundamentals, Frameworks, and Fiefdoms

I was equal parts encouraged and discouraged at this recent post by Uncle Bob.  As a software development community, we rally around the flags of .NET, Ruby, ASP.NET MVC, Python, Rails, Clojure or whatever platform, language, framework you want to throw out there.  I was encouraged that there are people, like Uncle Bob, who feel that craftsmanship and good practices can transcend language or choice of platform, but also discouraged that this opinion seems to be in the minority in the larger development community.  Another good read along the same lines is this post by Pierce Wetter, aka The Opinionated Bastard.

I started out as a C/C++ programmer (actually if you want to get technical my first professional programming was using Allen Bradley ladder logic) and eventually moved on to C#.  Along the way I was fortunate to find some good mentors who challenged me to improve my design and development skills and practice better ways of developing software through Agile and XP techniques.  This has pointed me in the direction of trying to keep up with new practices, languages, tools, and frameworks.

Along those lines, I have been dedicating some of my spare cycles lately to learning Ruby.  The initial draw to Ruby was that the Ruby community seemed to be focusing on good development practices.  I hope this adventure continues to lead me towards more good practices, more great tools, and more smart people to learn from.

I Hate Year End Lists

One of the things that drives me crazy about this time of year, is the never-ending set of lists for what happened in the last year, or resolutions for the new year.  Absolutely hate them.  So why am I writing one now, good question, I have no idea.  But if you hate lists and have stopped reading, oh well.  Anyway, here’s my lists of things to get done in 2012.

1. Set Up a GitHub Account – Really?!?!  It is the tail end of 2011 and I don’t have a GitHub account.  More and more it seems to matter less and less what is on your resume.  Show me what you’ve done.  Show me you can collaborate and play nice with others.

2.  Learn Ruby – I don’t mean dabble in Ruby.  I don’t mean write “Hello World” in Ruby.  I don’t mean write C# style code with Ruby syntax.  I’ve done that and it hasn’t mattered much.  Learn to write Ruby style code in Ruby.  Why?  Because maybe it will make me a stronger developer across the board by introducing me to different ways to write code and solve problems.  I also think the Ruby community as a whole are strong proponents of software craftsmenship.  Or at least the ones I run into are, and that can only be a good thing.

3.  Write More Code – The last few years I have spent a lot of energy working with Agile practices, and especially trying to help the teams I am on be more productive and write better, well-tested code through practices like pairing and TDD.  I am very proud of the end results, but a side effect of that has been that I write less code on a day to day basis.  That may require being creative and looking for new opportunities to write code outside of my day job.  But I really miss the challenges of solving technical problems on a regular basis.

4.  Read More Code – Participating in the Global CodeRetreat was a great opportunity to work with a lot of developers, all with different experiences and skill levels.  Being an experienced developer is great, but there is so much to be learned from seeing how other people solve problems.  Instead of just downloading some open source tool that makes my life easier, peek under the covers, run the tests,  I don’t know…maybe even contribute to the project.  At the very least get some new ideas.

5. Get Out of My Comfort Zone – Over the years I have developed a set of skills and practices that work well for me and that I have been successful with.  I wouldn’t say it is easy, but it is a little safe.  I have experience with problem domains I work in, I am comfortable with the languages I use, and I have developed a set of practices that are well ingrained in me.  That’s all well and good, but there is a potential for a lot of growth to be found outside your comfort zone.

6. Buy a Mac – Windows and Microsoft have been good to me, and I have used Windows for work for the past 20 years or so.  I will probably still do my day job work on a Windows machine, but in the spirit of learning new languages and getting out of my comfort zone, maybe it is time to see how life is from the other side.  I could do all these things on a Windows box, but it’s time for a little change.  Plus I can hang out with the cool kids at developer events.

So I am seeing a theme here for 2012.  Hopefully I can make it all happen.

Have a safe and happy new year!

My Day at Global CodeRetreat 2011

For those of you not keeping score at home, December 3 was the Global Day of CodeRetreat 2011.  I was attending the session hosted by the Boston Software Craftsmanship group at the Microsoft NERD location in Cambridge MA.

For those not familiar with the CodeRetreat concept, the day was broken up into several pair programming exercises, with a strong focus on Test Driven Development (TDD).  The exercises were centered around Conway’s Game of Life, a simple enough problem to understand quickly, but with a domain that still allowed for a variety of challenges and corresponding implementations.  There were several  languages represented at the Cambridge retreat: Java, Scala, Clojure, Ruby, C#, JavaScript, Python, PHP,  and probably a few others.

The first exercise was a simple pairing exercise with no rules other than to meet your pairing partner and get into te swing of things.  It was a good start up exercise.  I paired with a guy named Mark, and we did the exercise in C#.  We made a few classic mistakes like getting ahead of ourselves with the design, but we did a good job of keeping each other honest and quickly got back on track.  I enjoyed the session a lot, and the 45 minutes went by quickly.

For the next challenge, I wanted to try a different language.  I have been very interested in Ruby and sought out a partner who could give me a good intro to the language.  The exercises were ratcheting up a bit, and the goal of this exercise was to make your code as clear and expressive as possible.  Good naming, clear and concise tests, good design were the goals here, and Ruby did not disappoint in that regard.  You can program cleanly or poorly in any language, I have probably done both in my years of development, but Ruby seemed to allow a clear design in a minimalist style that read very well.  Alex was my paring partner for this exercise and he was very helpful in explaining some of the nuances and conventions in the language.

For the third challenge, we got into an odd constraint.  Your code could not have any exposed primitives.  Excuse me!?!?!  No bools, ints, strings, lists.  Um…aren’t these sort of key to programming…isn’t that why the are called primitives.  But staying in the spirit of the day, this is a chance to try new things and see where the exercise takes us.  Keeping with my goals for the day to try some different languages, I paired up with someone to do some Scala.  Working without primitives was a challenge, you needed to come up with some potentially contrived abstractions, but it got you thinking.  I had seen some Scala at the VT Code Camp, and was eager to see it in action, but unfortunately, Don and I had some start-up problems getting going with Scala, so  I don’t think I saw it at its best.  I was glad I tried it though and maybe I’ll have better luck next time.

During a break for lunch, where we also saw a really wild example of the Game of Life in APL.  I used APL exactly once when I was in studying Chemical Engineering at UMass back in the day.  I had a hairy matrix problem and someone said, you know what’s really good for matrix calculations…APL.  He was right, but wow, it is not like anything I had used before or since.  We all got a good laugh out of the exercise, because of the ease at which the author solved the problem and how unfamiliar it was to our normal lives as developers in other languages.

In the afternoon, I paired up with Abby Fichtner, the Hacker Chick, for an even more challenging exercise.  This time, not only no primitives, but no conditionals either.  That means no ifs, no ternary operators, etc.  This required even more creative ways to solve the problem.  Where as before you could make a decision on the live/dead state of a cell by asking “if the number of neighbors is….”, that was not an option in this exercise.  We decided to make an array of states that we could index into based on the number of live neighbors a cell had.  We banged our heads a lot trying to figure out how to solve a problem without conditionals, but we had a lot of fun and had to think creatively to come up with what might otherwise be a straightforward problem.

Next up was a silent pairing exercise.  In other exercises, the pairs switched often between who wrote the tests and who wrote the code, but in this exercise, one person was the designated test writer and another was the designated implementer.  The exercise was intentionally adversarial, as the test writer was instructed to write tests that poked holes in the design.  It was a lot of fun to see the interaction between pairs, especially the two guys who were sitting across from me.  You could see that it was a real tennis match, with each person returning the volley of the other.  Someone jokingly (I hope) commented that he learned that talking was overrated and he hoped to do it much less in the future.

The last exercise was to do the best design you could, with no other constraints.  I wanted to try Java, so I paired up with Tarish, who kindly helped me re-remember Java.  I learned Java about 10 years ago, but haven’t done much since then.  It’s a short walk from C#, but my brain was beginning to fuse and I don’t think I put my best foot forward with Java.  Tarish was really helpful, and I enjoyed the conversations we had about Agile and TDD as we went along.

We wrapped up going around in a circle, answering 3 questions: what did we learn, what were we surprised about, and what would we do differently.  For me I learned that Boston Software Craftsmanship is a really good group.  If you are in the Boston area and you want to improve your software engineering skills you should check them out.  I was surprised at how much fun I had working with the constraints like no conditionals and how it made me have to think more creatively.  And for what I would do differently, as much as I wanted to try new languages, in some cases that got in the way of fully experiencing the challenges and constraints, so next time I will brush up on languages I am interested beforehand and try to stay in some amount of familiarity/comfort zone.

To sum up, met some great people, programmed in 4 languages (C#, Ruby, Scala, and Java), and thought hard about different ways to solve problems.  Looking forward to doing it again.