Roman Numerals Kata with Commentary

I recently participated in an awesome Kata Battle at 8th Light against the worthy adversary, Craig Demyanovitch. The kata was the wonderful Roman Numerals Kata, converting arabic numbers to their roman numeral equivalent.

While practicing the kata, I noticed a lot of interesting things around the decisions I made in the solution. So, I thought I would record a katacast and lay over some voice commentary around it.

I'm putting two videos here, with and without commentary.

Here is the kata WITH commentary. It runs about 16 minutes and 40 seconds, so it isn't too bad to watch. I'd love to hear any constructive feedback in the comments. Version with no commentary is at the bottom of this post. I'd highly recommend watching it full-screen, so you can actually see it.

Resources:

• Transformation Priority Premise
• 4 Rules of Simple Design
• Roman Numeral Kata

Here it is with no commentary, if you just want to see me run through it at a reasonable speed.

Being honest vs Making excuses

The other day, I was involved in a conversation with a group of developers. Several of them work at a large company whose product is built on Ruby on Rails. We were talking about the development environment there, specifically the test suite. The codebase is quite a few years old and has a very slow test suite in part due to some design issues in the codebase. I asked what their test suite was currently running at, and I don't remember the exact figure, but it definitely had a lower bound at 30 minutes (I think it might have been an hour). I then asked about just the unit test suite, the one you should be running frequently while developing. The speed for that was on the order of many minutes. Someone else then asked how it was to run a single set of examples, the type that's focused on whatever part of the codebase you're actively working on, the type that should be run almost constantly while writing code. This was 'better,' being on the order of 30-45 seconds. I remarked that this was still horrible, especially when working on a piece of the system that didn't need specific features of Rails*. One person remarked that this was inevitable with a large codebase. I disagreed. That is, I disagreed with the statement that the size of the codebase was the cause. Slow unit test suites and the inability to quickly run focused subsets are an indication of a design problem with the codebase, not the size. As we talked more, I started to notice something that I've seen before but had a hard time placing: extreme rationalization of bad situations.

This got me thinking. Often times, we choose to be in certain situations and then, rather than admitting that the situation is bad and dysfunctional, then convince ourselves -- and justify to others -- that this is the only way it can be. While we are free to choose trade-offs for whatever situation we place ourselves in, it is important to be honest with ourselves about the causes of the situation. For example, the above company has interesting computer-science-types of problems which makes up for the bad situation regarding the actual development process.

If we are not honest about the causes of a bad situation, we pose a significant danger to those who are either less-experienced or uncertain about their own situation. Take a slow test suite, for example. Having a test suite that actively hinders a developer from running portions of it while developing is a deterent even to run the suite at all. As the run time climbs into minutes, the test suite becomes an antagonist, rather than the helper and guide that it should be. Instead of rationalizing, say you have some serious design flaws in your system. Or, say you have a large codebase and a huge team consisting of people with varying desires to write automated tests. When we mask the real causes of a problem, it has the potential to confuse less-experienced developers who look to us for guidance. For example, thinking a slow test suite is inevitable could stop someone from asking for help optimizing their own codebase while there is still time. If you are talking to a less-experienced developer and you mask the fundamental problems, what message are you conveying to them?

The point of this post is not to point out how people are wrong or that you have to fix, or are able to fix, a bad situation. I just want to raise a reminder that there is a difference between rationalization and being honest with the reasons for something. By rationalizing, we are fooling ourselves and those who learn from us into thinking that you can't do better and it isn't worth trying. By being honest with the reasons, we have the opportunity to both learn from our mistakes, and teach others what pitfalls might await given certain decisions.

So, the next time you find yourself talking with someone and describing a less-than-optimal situation, ask yourself whether you are being honest about the causes. It doesn't mean you have the power or inclination to fix the problem, but talking about the causes can lead to valuable conversations about how we can do things better in the future.

also... can we stop using the terms 'ivory tower' or 'real world' when rationalizing our situations? As DHH said, "The real world isn’t a place, it’s an excuse. It’s a justification for not trying." (other inspirational quotes)

*In fact, I will put forward you can't do an effective test-driven development cycle with a feedback loop that long.

As always, thoughtful comments are happily accepted.

My talk from SCNA2010

I was honored to be asked to give the closing talk at the Software Craftsmanship North America conference (SCNA) last year. It was a fantastic event filled will great thought, exciting conversations and wonderful people. This was the talk I gave introducing the idea of positivember.

Dates have been announced for this year's version of SCNA, November 18-19, 2011, so make sure to go check it out.

The video from my talk has been put up, so I wanted to share it. You can watch it on this page, full screen or click over to vimeo to watch it.

SCNA 2010 / Corey Haines from Brian Pratt on Vimeo.

Turbulence, measuring the turbulent nature of your code

Recently, Michael Feathers has been investigating the idea of mining all the data in our source code repositories to start finding information about our codebase and system design. He wrote an article about possibly using a churn v complexity chart to look for areas that could use some refactoring love called "Getting Empirical about Refactoring".
Since he has joined Obtiva as Chief Scientist, he is here in Chicago fairly frequently. I had the pleasure of spending a morning with him, and we naturally talked about his ideas. I was inspired to build a short bash script that generated a churn graph for my own codebase on MercuryApp. Chad Fowler took my short script and merged it with a script he wrote to run Flog over the codebase. While Michael, Chad and I were in Boulder, CO, for a coderetreat this past weekend, we put together a project called Turbulence.

Turbulence is a gem that you install and run in the directory of your code. It does a churn report, combines it with Flog data, and generates a nice scatter plot view. You can find instructions on the Turbulence project page. Although it currently only support Ruby code, we have plans for expanding the project to support other languages.

One goal is to have people take a screenshot of their graph and post it to twitter with the hashtag #codeturb. This will allow us to view the graphs on hashalbum and see what we can see.

Another goal is to have people send us their data, so we can do some analysis on different contexts. If you'd like to take part in this project, please email me. We are working on finishing up an anonymizer function that will mask the filenames, in case you might worry about directory structures/file names giving away your codebase's dirty secrets.

We are also proposing a series of talks at conferences outlining both results, recommendations and tools for helping analyzing your design based on the shape of your metrics. Keep watch for those.

I've uploaded my current graph for MercuryApp, you can see it in all its glory by clicking on the picture below.

On the goals of Coderetreat

Last Sunday, I facilitated a coderetreat in Cleveland, Ohio, at the Leandog Software boat. It was a great time, filled with writing code, practicing technique and learning both obvious and subtle lessons. I'm always excited to see people's reactions about the event (for example, here and here), as they gain more insights into their journey. Over the past two years, I've found my own role as facilitator transform into a guide, poking a bit here and there at the code.
The full benefits of coderetreat come clear through the course of a whole day, starting with a session, or two, of understanding the problem domain, then the rest of the day is spent pushing our limits, accepting that our 'normal' way of coding isn't enough, that we should be striving towards an ideal. The format of the day is structured very specifically to allow for this experimentation. This is a reason we start early and I don't support having people 'drop by': we want time to get over the 'hacking away to finish' mentality that normally accompanies time pressure and brings with it the necessary corner-cutting. Focusing on improving our skills over 'getting it done' is one of the primary aspects that sets us apart from just being another hackfest: we are practicing to get better at the fundamentals. For example, we aren't there as a way to primarily practice or sell TDD, we aren't there to work on design patterns, we aren't there to finish the problem. We are there to work on learning better software design skills through exploration of the 4 rules of simple design. This is done through experimentation and exploration.

'Taking it too far' v 'Taking too much time'

Coderetreat is about spending the day writing perfect code. During our day-to-day programming tasks, whether they are for pay or our side-projects, we always have the end goal of getting something done. This inevitably causes us to cut corners, writing less-than-perfect code. Why do we do this? For one, it is because writing the code that we 'know we should write' will take too long. We have to weigh the value of merciless refactoring and ultimate clean code with the reality of the benefit we get from delivering something. At coderetreat, though, the pressure to finish goes away, deleting the code makes it so that you can't finish the problem. This allows us the freedom to act as though we have an infinite amount of time.

As I've traveled around and had the opportunity to work with people of widely varying experience and skill level, I've noticed that the big difference is which corners get cut. For people with less experience, say 1-5 years, the 'get it done' code is significantly different, less clean, than the code written by those with a lot more experience, say 15-20 years, yet written in the same amount of time. This makes sense and isn't a knock against beginners, it is just a good indication that there is always more to learn. The gap between what we actually write and what we think we would write given enough time is always there, just at a different level. As we gain more experience, that gap simply moves upward, so the code is cleaner given the same constraints.

I've facilitated a lot of coderetreats. I've watched people of widely varying skill levels work on the same problem. Some will write very readable code, others will write less readable code. My role as a facilitator is to ask the questions about the code, questioning the refactoring decisions, and, more often, helping people understand why they stopped refactoring.

Suppose you have this method, a very common one used to figure out whether a living cell will die in Conway's Game of Life:



Commonly a team arrives at this and moves to the next test. I'll ask if they aren't skimping a bit on the refactoring and get a response similar to "well, we don't want to go too far" or "this is very readable." I'll generally add a little code:



That is clearly more readable; most teams that see this small change agree. My question is "why did you stop?" The readability also exposes a few other problems, mostly around the method names, but that is a topic for a different blog post. So, the question remains "why is the first form 'good enough'?" After all, the extracted version is more readable, captures the domain better (underpopulated vs a cryptic number comparison) and is not much more work to extract, especially with basic refactoring support.

[Just a note here that this is not the absolute end state of the system, but an intermediate step along the way of evolving the design. If teams get that far, this usually ends up being extracted into another object that resolves some of the design issues inherent in it.]

One hypothesis is that we often mix up the idea of "going to far" with "taking too much time." After all, I would be surprised if someone would say that the extracted version truly is taking it too far. However, I do believe that some people would argue that it might take them too much time to do this all the time. I've worked with people who didn't have a good understanding of their toolsets, so this sort of extraction would take more time: manually extracting it doesn't take a lot of time, but it is definitely non-zero. So, creating code like this is time-consuming on a larger scale, so we don't do it. This, though, is really about "taking too much time."

Another hypothesis is that we aren't comfortable with more abstractions. For various reasons, most of us don't have a great familiarity and comfort with abstractions. One difference I've noticed between people with varying experience levels is a view on abstractions and how they handle them. I like to say that programming is based a lot on just being adept at abstraction wrangling, and my experiences with people has shown me that this has more than a hint of truth to it. As we encounter the creation and manipulation of abstractions, we get a better sense of where they are hiding in the system and how to be effective in drawing them out into the open. A common argument against heavy abstraction is that you then have to jump around the system to see what is 'really' going on. For people who are truly comfortable with it, though, you either don't need to see what is 'really' going on, relying on the names to truly reveal their intent. And, when you do need to see what a specific part of the system is doing, navigation can be a trivial act, due to a clear signpost guiding you to your destination.


These are just musings of mine. I don't have the answers; these thoughts are based on my experiences pairing with different people and watching people of various levels writing the same problem over and over at coderetreats. I'd love to hear any ideas that others have either in comments or as blog posts. I think this is an important topic that can help us understand ourselves better both as a means of accurate self-assessment and developing more effective training mechanisms.

Positivember

At the 2010 Software Craftsmanship North America conference (SCNA), I was given the honor of giving the closing talk, titled "The Long Road Ahead." (watch here) My goal was to focus on where we had come and where we are going as a movement, not only looking into the previous year's activity, but also what might stand in our way of spreading the ideas of craftsmanship to the general programming communities.

As I was preparing, several conference talks influenced my thoughts and the focus of my presentation.

At jRubyConf, Joe O'Brien gave a wonderful talk about how the people around us are not stupid and not worthy of the scorn often laid upon them. Instead, we should consider them experts in their domain helping us better build the software we are hired to make. At the same conference, Glen Vanderberg provided a informed view of the problems with the term "software engineering," and what we might do to establish ourselves as a true engineering discipline, all the while capturing and celebrating the artistic, creative bent on which we pride ourselves.

At SCNA, Doug Bradbury gave a great talk on our inclination to build, to make; we need to get back to our roots, back to our core qualities as makers.  Deep down, we are all creators; we start with nothing but a blank screen, and we put our hearts and souls into the creation of something real, something that acts and solves problems. We write new creation myths every day, except ours reach up out of myth and into reality. Chad Fowler gave an inspiring talk on readdressing what we thought of as quality, putting forth the challenge to merge the realms of art and utility. Often, we hear the argument that the craftsmanship principles are unrealistic and potentially harmful to production; Chad's talk was a refreshing counter to these, showing that we can support both.

While there is no 'craftsmanship canon,' these talks, for me, cut to the core of the craftsmanship manifesto, highlighting the fundamentals of what we do and care about. They were wonderful examples of how the fundamentals have crystallized over the past two years. Looking forward, the question of spreading the ideas is moving into the spotlight. The ideals are sound, so what could stand in the way?

Considering the topic of what might hold us back, I watched the mailing lists, I read blog posts, and I paid attention to the twitter stream. I thought about what would set us apart as a movement, and, on a larger scale, what were some hurdles that the software industry as a whole faced. There were a lot of thoughts, but one thing really stood out: we are an overwhelmingly negative group. We complain about our hours, we complain about our jobs, we complain about our coworkers, we complain our toolsets. If we are going to become better, we need to change this.

I believe that a significant factor impeding us in the goal of selling to those around us the care and professionalism espoused by the craftsmanship movement is the negativity we propogate. So, in my SCNA talk, I challenged the audience to take part in what I am calling "positivember." That is, one month, just one month, where we guard ourselves from the trap of negativity, during which we filter ourselves from taking part in the easy trap of those little comments that we put on twitter, the offhand remarks that we make on our blogs, the complains we focus on when we spend time in person. One month where we put forward an air of positivity in all of our dealings. What would happen if we all did this? What would be the result if we took a minute before we complained, a moment to reflect on whether our dissatisfaction is because of our own choices, those decisions we have made about our tools, our coworkers, our entire work environment?

So, I ask each and every one of you to take part in this grand experiment: spend a single month portraying only positivity and happiness in what we do. After all, we have one of the greatest jobs there is. We get paid to do that which we gladly do for fun, for a hobby. I spent my teen years programming, relishing the thrill of creation, the thrill of making. Now, more than 20 years later, I get paid to do this. We all do.

Join with me this November to celebrate the beauty and happiness in what we do. Try to take a moment to filter every outward expression of yourself and look for the joy in what we do. We all get frustrated at times; the world isn't perfect. But, if we can take a second to reflect and focus on the positive, maybe that will actually have an effect on our industry, and on our world.

The hashtag for this is #positivember. This word captures the essence of the movement: 'positiv' stands for looking forward, appreciating the life of creation that we have built for ourselves, being proud of what we are doing; 'ember' is hungarian for 'person,' the simple link that this is about us as individuals. So, I ask you to help spread the word: tweet about it; blog about it; talk about it. Most of all, present yourself as a happy, positive person who cares about what they do. As people see that those of us who care are happy, they will want to know why. When they ask, we can proudly say, "I love what I do. I'm happy doing what I love."

And, in the end, I believe this to be the only way we can convince others to follow along. Will you join us?

Help support #positivember

• Please vote for this on Digg, so we can get more people taking part.
• Do you have a podcast? Please give us a shoutout. I'm also available for short interviews about the motivation behind it.