Starting with a test means that we have to describe what we want to achieve before we consider how.

Here’s a snippet from the official GWT MVP tutorial:

In this example, you see that our Presenter, when bound, registers a click handler for a button, in order to perform some action when it is called. This might seem nice and all, but there’s a smell. This is a violation of the Law of Demeter (the missing SOLID rule, one might say). This simply makes it harder to test, since we now have to add another layer of indirection between the SUT and its collaborators. Instead of making the view a tiny bit smarter, we use it as a dumb collection of widgets the presenter manages. This is clearly not in “Tell, don’t ask” form.

The thing that really bothers me is how coupled the presenter gets with its view. Take the above example, and say that you decided that it would be better to have two “save” buttons on the UI. Does the presenter really care? Should it even change? And what if you actually want the save button to change to a remove button when the user picked something? Should the presenter now deal with getSaveOrRemoveButton() ? Of course not.

GOOS it up

After beating around this bush for quite some time, I decided to try and find a better way. I’m currently reading the brilliant Growing Object Oriented Software book, and decided to try its approach to push a better implementation. After a bit of refactoring I got this:

This might seem like a tiny change. And it is. But it makes all the difference in the world in how more responsive your design gets, especially in our world where the view is most likely to change a dozen times before settling on something. Once there are enough of these, I push the presenter as a dependency into the view, and let it call the presenter directly. The funny thing is this style is actually implicitly mentioned in the second part of the GWT MVP tutorial. Just some GOOSing helped us get to a better, more malleable design!

Don’t be afraid to do something differently than the documentation, especially if you gave it a fair shot and it didn’t work out.

You should subscribe to my feed and follow me on twitter!

The meeting was composed of 3 tables: a code review table where people actually brought code from home/work and discussed about with others, a TDD table where a veteran TDDer talked people through a Kata and a third table, led by yours truly, that aimed to introduce people to the concept of DRY and tackling some duplications problems.

Unfortunately for me, this means I couldn’t take part in the other tables, but from what I could pick up I must say it was really fun getting so much positive feedback for a meeting.

The DRY table consisted of a Kata I’ve composed specifically to raise issues of duplication already a few minutes into it, which you can find here. It was amazing seeing people keep working on the Kata after the 1-hour dedicated to it was up, and I never expected to see such variety (Java, C#, Python, Ruby, JavaScript and PHP were all spotted)!

The slides from my (extremely) short introduction to DRY are available here:

DRY – Don’t Repeat Yourself

You should subscribe to my feed and follow me on twitter!

A few notes:

• After completing a step in the Kata and before moving on to the next, take the time to make sure your code’s duplication ≤ 0
• For the sake of focus, you may ignore matters of character escaping, encoding, error handling, object graph cycles and the likes
• Our focus is on reducing duplication, it is not finishing the kata

In this Kata, our goal is to implement 2 simple object serializers. One serializer is to XML, the other is to JSON.

1. Support serializing  a class without any members
   1. To XML: EmptyClass -> <EmptyClass></EmptyClass>
   1. To JSON: EmptyClass -> {}
2. Add support for serializing a class’ integer members
   1. To XML: IntClass(a=1, b=2) -> <IntClass><a>1</a><b>2</b></IntClass>
   2. To JSON: IntClass(a=1, b=2) -> { “a”: 1, “b”: 2 }
3. Add support for serializing a class’ string members
   1. To XML: StrClass(a=”first”, b=”second”) -> <StrClass><a>first</a><b>second</b></StrClass>
   2. To JSON: StrClass(a=”first”, b=”second”) -> { “a”: “first”, “b”: “second” }
4. Add support for serializing a class’ other class members
   1. To XML: CompositeClass(inner=(a=1)) -> <CompositeClass><inner><a>1</a></inner></CompositeClass>
   2. To JSON: CompositeClass(inner=(a=1)) -> { “inner”: { “a”: 1 } }

If you found this interesting subscribe to my feed and follow me on twitter!

Only after I started practicing TDD did I realize how significantly DRY can drive coding. Whenever I test drive code, the third step of the cycle, Refactor, is usually a lot about removing duplication. And the amazing part is that this alone drives a useful implementation. In the awesome book TDD By Example, Beck describes a method of implementing called Triangulation. It’s for those rare occassions where you really have no real clue what way is best to solve the problem – the ground that allows TDD to flourish. In this method, you start by getting a couple of tests to pass with dumb implementations and then refactor to generalize the code and make it DRY. The mere act of DRYing your code can simply through a solution at you. I’m still amazed when this happens to me, both because of the sheer beauty of the process, and because it means I’m doing something right.

About 5 years ago, when first heard about the concept of TDD, I wrote a greenfield project for about 5 months in what I believed was TDD. Only more than a year later did I realize that I wasn’t doing TDD at all, but TFD (Test First Development). I did in fact write all my tests before I wrote production code, but I didn’t let the tests drive the development. Now although that is better than not testing at all or TAD, it just wasn’t it, and I didn’t get why.

Whenever I wrote a test, I already knew how the implementation was going to look, be it simple or complex. Sometimes I might have alreayd decided that I was going to add a decorator there, and then wrote the test that forced me to implement a decorator. This, of course, is wrong. When I learned to let go and stop micro-managing my code, things took off at a better direction.

I write a simple test that explicitly uses the code as I would like to use it had someone else already imlpemented it. This is crucial, as it makes sure that I am not allowing myself to sustain a lousy interface simply because it’s the easier one to implement. The harder part is to always disconnect yourself from prejudice – what you might think the code should become. Currently this is a deliberate effort for me, to make sure I’m not thinking a few steps further and adding what I think I’ll need then too early. Even adding code I believe I’ll just have to add anyway in about 2 tests is wrong.

After making the test pass by the simplest way I could come up with I start DRYing the code up. I actually do more stuff, such as improving naming etc. but generally, DRY is the main force behind the changes in this phase for me. I listen to the code and try to make it. This is where knowing your refactorings well pays off. I might extract a method only to inline it 20 seconds later and extract a different part of it. I move things around a bit and see what feels right. Because I’ve already got the tests, there’s no reason not to use them right away to see just how far I can stretch the code to my ideal vision.

For me the magic is when I notice, after 30 minutes of doing this, that I’ve suddenly got a solution without realizing it. Suddenly the code falls into place. A lot of the times it turns out simpler than what I thought I’d turn out with.

Jumping from basic DRY to full blown TDD isn’t easy or straight forward, but let DRY drive you design for a while and see it grow on you. I’ve yet to meet someone that’s given it a shot and disagreed this a whole new way to programming.

Well, of course that’s not the case. Even the best programmers occasionally dig themselves into a hole that will require some effort to get out of. The point is that the best thing to do is never to take those 2 days to 2 weeks period just for doing that refactoring. That is never the right approach to solve such a problem.

First of all, I’ve seen many times that it was intended to spend “only” 2 days (which is already a huge amount of time) to do some refactoring, but 2 days in, the dev team found it they actually need 2 more days because of extra complications they’ve got, and the team’s lucky if after a week of hard work they still have a working system, not to mention better.

Another problem with that is, once the devs think they have a picture in mind of this perfect redesign that management won’t let them take a week to get to (with good reason!), a lot developers stop thinking about how to make the current code better. It’s just let’s add this hack here, because management won’t let us do this the right way. That’s BS. Will you come to your dentist 3 days in a row for ‘general groundwork’ before have a 2 hour filling? I thought so.

Programming is about adding value. Don’t get me wrong, I like writing elegant and clean code as much as the next guy (actually, probably a bit more given I walk around with one of these). But, what we’re hired to do is solve problems and help someone’s life by doing it. If all we do is bitch about how the design could be better, we’re only benefiting ourselves, and not doing a good job at it.

So what is the right way? Well, the right way is to pull things off towards the right direction, in steady and controlled baby steps. I’ve seen this work, and I’ve heard from much better programmers than myself that they’ve got it working multiple times. After spending a day in an awesome Responsive Design workshop by Kent Beck, I was a bit amazed to hear there are so many ways of pushing design towards a better place in baby steps. Up until that point I would have done it anyway, but Kent taught me there’s actually an art to it.

Do you think it’s impossible in your case because “X is too big”? Well, say you’ve got N steps in your redesign, all are safe atomic changes. Many of the times you might think the order of steps you’ve came up with simply won’t do and it will be too hard to do it without the big blunder. But, think about it this way: Those N steps have N! (N-factorial) different ways to be ordered. What are the odds that none of those ways will solve your problem? I’ve yet to see when this is not the case (and this, among others, is why you should spend the time with better and more experienced coders, such as Kent).

Yes, it means that “2 day refactoring” of yours will probably be spread over 2 weeks (which is just might have done anyway). But it also means that no matter what happens during those 2 weeks, you’re always on the safe side. Find out after 2 days that your idea simply won’t cut it? Well, no biggie. The code still works, and you added features those 2 days. Find out it’ll take longer? Yeah, so what. We’re doing a few small steps a day anyway. The awesome thing is that you’ve got time to learn during the work what you may have thought up wrong and use that as input for the next parts of the refactoring. No rush here. And I think the most important point is that if you simply spend 30 minutes a day to refactor things at the right direction, weaved into your daily work and refactorings, you’ll get it done without have to pitch your Big Redesign to management.

This allows you to simply do what you’re supposed to do: add value to customers daily, while making sure the system stays responsive to future changes. And that, my friends, is how the big refactoring should be done.

You should subscribe to my feed and follow me on twitter

It has been written a lot about that the term refactoring is being heavily misused lately. Have you ever said “we need to do a big refactoring here?” If so, you’ve done the term wrong. The Big Refactoring is the new Big Redesign in the Sky. Have you ever told your boss you need time to refactor something? You’re doing it wrong. Wrote Refactoring as a task on the board? Wrong once more.

Refactoring should be engrained in our constant flow of work. I mean it should be assimilated into the way you think of basic coding. Stop thinking of code changes as a stream of characters. To be an efficient coder you need to think of code at a higher level. The level of refactorings should be the level we think of code.

I really believe that generally typing is not the bottleneck. In spite of that, I believe that being able to perform refactorings quickly, efficiently and seamlessly as part of your flow is a major differentiator in one’s ability to quickly check ideas and be able to push design forward. I’ve deliberately spent time to put all refactorings of IDEs I use into my muscle memory. Extracting a method is not some heavy mind process, it’s just a swift movement I do with my fingers.

An interesting example of how refactorings should be used I’ve heard from Kent Beck is his way to perform changes cohesively. Say you’re editing a method 10 lines long and need to perform a change on 2 lines in the middle of it. Most people might simply make the change, but Kent (at least some of the time) will extract those lines to a new method and make the change in that new method. If the new method feels right after the change he’ll just leave it there. If not, he’ll inline it. If you’re thinking that’s a lot of hassle, you’re missing all the fun here. This whole process has an overhead of 1 second on most IDEs, given you don’t have a hard time coming up with a name for the method.

Doing refactorings the right way means you do dozens of refactorings on each coding session. This means you get the ability to tailor your code in much bigger chunks – methods, members, classes, interfaces. After all, we usually don’t think about the need to move those parenthesis – we think about intent. Refactoring is all about intent!

Do yourself a favor and note your use of refactoring for a week. Learn all the hot keys your IDE has and make it a point to use them whenever possible. Whether you’re doing Java, C#, Python or Ruby, there’s no excuse not to use these basic building blocks for your every day use. Our stream of changes should be made of a lot of small, constant refactorings, pushing our design to a better place one small step at a time. Getting so familiar with this technique means you will no longer need to ask your boss for refactoring time. You won’t need those big refactorings. You’ll stop thinking about refactorings so much, they’ll simply happen.

Refactoring’s no longer a buzzword, but it’s time for us to learn how to use it properly. Refactor constantly and get your groove on.

You should subscribe to my feed and follow me on twitter!

The problem is, that as with any skill, you have to learn to master even the corner cases and not just blindly follow a mantra. Following a mantra is good enough for starting everything, but there comes a time you have to experience and understand for yourself when using a rule of thumb is a good idea and when it isn’t. So, let’s now talk about the ‘Ha’ part of the ShuHaRi cycle in DRY.

We know that duplicate code is a code smell and a DRY violation that needs to be removed. But, as with any rule, it has exceptions. Taking the dumb example, look at this piece of code:

In the snippet above you can see the value ’0′ referenced twice. Is that a DRY violation? I’m sure you’ll agree it isn’t. After all, even though it is the same value that appears multiple times syntacticly, it has a different meaning semantically. The first zero is an initialization value and the other seems to indicate bad values in the array. The fact that they both are zero is meaningless and a coincidence. It might very well be that the next version will mark bad values as ‘null’, which surely shouldn’t change the way the array index is initialized. OK, so that was an easy one. Let’s look at this next snippet, taking from some code whipped up solve the Game of Life:

In that example, 2 appears twice also. Is that a DRY violation? After being in a code retreat, and hearing from other code retreaters, I understand that many people that try and focus on DRY think that is in fact a DRY violation. After all, both occurrences refer to the number of living neighbours a cell has and the number is part of the rules of the problem domain. But, let’s give this a bit more thought. Although both instances of 2 reference a rule of the game, they reference different rules of the game. Semantically, they are different. If we decide to change the minimal number of neighbours for a cell to stay alive it does not mean we will want to change the number of neighbours it takes to bring a cell to life.

I hope you’re catching my train of thought here. Now let’s look at another example. This is a snippet of code one might get to while doing the famous Bowling Kata:

This snippet adds the current frame’s score to the total score of the bowling game, taking into account whether the frame has a strike, a spare, or is a ‘simple’ frame. Now, you might notice there is some “duplication” here. I can tell you that when I started refactoring this code to make it look better, I had to think a bit whether the calculation of the score in the first branch and the second branch should be extracted to be the same method.
But again, this is a mere textual duplication, and not a violation of real DRY, which is duplication of intent. The first one takes the score of the strike frame itself and adds the strike bonus (2 next rolls), the other takes the score of the spare frame and adds the spare bonus (1 next roll), so even though it takes the same additions, it is not the same logic. The better way is of course this:

This is a tricky one, and if you noticed it before reading give yourself a pat on the back! If you start and refactor this with an IDE, most IDEs will actually make a bit of a mess for you here, because they usually try and replace same occurrences of code once you extract a method, but here that would not be the better choice. Always keep an eye on your refactoring tools, because they, unlike you, can’t tell the difference between syntactic duplication and semantic duplication!

The big money of DRY comes when you learn to tell the difference between duplication of intent and mere duplication of text. This simple rule for judging your code helps you understand your code better, simply by making you actively consider what your real intention is.

I’ve written more about DRY here and here if you’d like to hear more.

You should subscribe to my feed and follow me on twitter!

DRY can be used extensively in your code base to alert you of problems waiting to happen. For example, similar code structures in different parts of the code are usually a DRY violation. This violation causes coupling which in turn will make it harder to change the code. The good scenario is that you have to tediously go through all the repetitions and change them to accommodate the change. The worse case is you forget to change one and introduce inconsistency in your code.

Train yourself to note these feelings of “yeah, I’ll have to do that again here”. Lucky for me, whenever I do something too many times I automatically start referring to it as “the dance”. So, once I hear myself saying to a teammate that “I’m doing the add-view-dance” I know it’s time to do something about it.

But DRY need not apply only to your code. Actually, it certainly shouldn’t! Copying is bad, even if you do it in a configuration file, or “just in that script”. It’s our tendency to disregard these “minor” parts of our system as not worthy of our attention, but these are places that are at least as likely to cause problems as our code. Taking the time to make the deployment scripts tidier will pay off once you decide to leave that server at home and deploy your app on EC2.

DRY used correctly will make driving changes in your app a breeze, be it a configuration change, a DB change or a real feature you need to add. The saved cycles of work saved by not having to dig around the code and look for other places your forgot to update, or hunt the bugs caused after making a change pay off immensely for the time spent on making things the good way.

Let’s take this one step further. Do you document your app? For example, do you supply wiki pages with explanations for installing the system, executing it or making configuration changes? There isn’t a coder out there that hasn’t been bitten by an outdated guide that was updated to reflect the way things should be done now. This is a subtle DRY violation – the is repetition between the description of the process in the wiki and the real process, as is usually saved in people’s heads or scripts. If you’ve got a script, why not simply use it as documentation?

Most people will probably understand your shell script better, and it is sure to be up-to-date. I tend to document the script itself to make it clearer (and generally treat it as part of the code base) which pays off when I don’t have to hear people get angry with me for not updating the wiki.

The even more important example is sample code. Almost every app will, at some point, require you to supply sample code for working with it. The knee-jerk solution is to hack some code and put it on a wiki page. You might even go the extra mile and run the code to make sure it works. 24 hours later, you change the code and the samples are now obsolete. Again, duplication between real code and sample code has created a problem for us. The solution, once more, is to fight this duplication. Putting the samples as part of the app’s version control, which will make sure they compile and run with every change, and pointing the wiki to these files (or even embedding them in the wiki) will save you a great hassle. Sometimes you can even make these examples part of the code, such as Python’s Doctests, which allows you to put executable usage examples right next to the code.

Once more, training your senses to notice these violations and finding creative solutions for them takes practice and time, but gets a lot easier once you get the trick. This is a crucial tool in the pragmatic programmer’s belt.

DRY, actually, is a measure of technical debt. The more violations you allow to slip in the codebase, the harder you’ll have to work later to change the code. A DRY codebase is usually more cohesive and loosely coupled which leads to a more responsive design. Effort you put into keeping your code DRY pays off, quickly and by manyfold.

You should subscribe to my feed and follow me on twitter.