Refactoring or Redesign?

If you ever worked on a software that has grown organically over time, you will agree that many candidates for refactoring can be found in it. These are identified as pain points, smells or simply things that suck. The reason is that as the software grows, requirements change and code needs to adapt in order to support these changes.

JIRA is not an exception. JIRA team will spend around 30 hours in each eight week release cycle on refactoring of existing code, improving design, making it easier to extend the current code base with new features. At the iteration planning meeting last week, my colleagues and I were discussing how to spend this time in the most efficient way, debating what is refactoring and what is not. One of my colleagues raised a question: "Is is refactoring or redesign?"

The answer is: "It's both."

According to The Pragmatic Programmer: From Journeyman to Master written by Andrew Hunt and David Thomas:

At its heart, refactoring is redesign. Anything that you or others on your team designed can be redesigned in light of new facts, deeper understandings, changing requirements, and so on. But if you proceed to rip up vast quantities of code with wild abandon, you may find yourself in a worse position that when you started.

Clearly, refactoring is an activity that needs to be undertaken slowly, deliberately, and carefully. Martin Fowler offers the following simple tips on how to refactor without doing more harm than good:

1. Don't try to refactor and add functionality at the same time.
2. Make sure you have good tests before you begin refactoring. Run the tests as often as possible. That way you will know quickly if your changes have broken anything.
3. Take short, deliberate steps: move a field from one class to another, fuse two similar methods into a superclass. Refactoring often involves making many localized changes that result in a larger-scale change. If you keep your steps small, and test after each step, you will avoid prolonged debugging.

Good Design

I am back from the wonderful trip to South Korea, where my wife comes from. We spent some time sightseeing Seoul and some time meeting with Miae's relatives. I am already looking forward the next time we visit Korea and will travel around the country.

Before one of the meetings we had, I had to go to a restroom. It was in a very luxurious 5-star hotel. As I was sitting there and doing my business I noticed a little white box mounted on the wall. This little device had a display and many buttons. As I can read Korean script (Hangul), but have no idea what I read, I had absolutely no clue what this magic white-box is for. Naturally, I knew there was a connection with the human waste disposal unit I was sitting on.

What was even worse was the fact the the most common button - FLUSH - was nowhere to be found. I checked the usual spots around the toilet, but I found absolutely nothing. So I decided (as a citizen of a developed country and an educated man) that I have to have a crack on this thing and must be able to flush using basic logic and common sense.

Koreans are probably laughing at me right now, but I failed miserably. I pressed few this-must-work buttons, but could not make that damn thing to flush. So I left with shame, leaving a surprise present for the lucky person who would come after me. Luckily, no one was waiting so I got away with it without too much embarrassment.

This whole story reminds me of an excellent book I read long time ago. The design of Everyday Things by Donald A. Norman talks about the good and bad design of things we use everyday. He says that if things are designed well, no manuals, no labels, no description text is necessary. You simply grab the thing and use it in a right way. How many times you tried to push the door that was meant to be pulled just because the door handle was easier to grab and push? How many times you pushed the wrong light switch because the switches were not in logical order?

Well, I don't know if it was me this time or a bad design. Why do we need so many buttons for the toilet anyway?

Pair Programming Habits

I finished reading Pair Programming Illuminated, a book written by Laurie Williams and Robert Kessler. I talked about this book in my previous blog: "The Seven Myths of Pair Programming". I really enjoyed reading this book. It's time to put it back the shelf, so other developers in our office can get their hands on it, but I am sure I will come back to is sometimes. I want to talk a bit about one of the chapter at the end of this book.

Seven Habits of Effective Pair Programming

Habit 1: Take Breaks

This was one of the things that we identified early on. Pair programming is a very intensive activity. We worked in pairs whole day. And then at the end of the day, exhausted, we were still in the office catching up with the pile of e-mails and other administrative stuff. Take breaks on regular basis. Have a coffee, tea, talk to other developers, stretch, do whatever - simply, have a break!

Habit 2: Practice Humility

One of my favorite quotes that I use on daily basis: "Pair programming makes me feel stupid everyday. I love it!"

Habit 3: Be Confident / Be Receptive

Do not be afraid to appear dumb. Nobody expects you to know everything. You do not expect the others to know the answers to all your questions, do you? And remember, this is a teamwork, not a competition.

Habit 4: Communicate

This is very important. Today I had an encounter with one of our staff. He is not usually exposed to pair programming that we practice in our team. He came over to my computer and typed commands rapidly on the command line. No words said. I could not follow him. I was not experienced enough in that particular area and wanted to learn from him, so I asked him if he could comment what he was doing. I felt stupid again... but hey, I learnt something!

Habit 5: Listen

This is important as well. We all dive deeply into our thought when we type away our code. Sometimes I found myself not really listening to the navigator. When I finished, I had to ask what he said and reiterate thought his thought.

Another case is when you listen but assume you know what he or she is going to say. Do not assume. Listen! If he or she wants to say something, there is probably a good reason for it.

Habit 6: Be a Team Player

No much to be said here. Just be part of what is happening. Be actively involved in the process, whether it is coding or just thinking as a navigator. You need to be able to understand what is going on at any moment. If you don't, ask!

Habit 7: Hone the Balance between Compromise and Standing Firm

It's hard to find balance if you try to go separate ways. Always think that this is a teamwork and the way the project should be heading.

The Seven Myths of Pair Programming

I am lucky that I work for a company that embraces XP. Moreover, there are lots of interesting books on the shelf in our office bookshelf; books about XP, Java, Software Engineering and many more.

Last night, I started reading Pair Programming Illuminated written by Laurie Williams and Robert Kessler. It is quite easy reading and I will share my opinions about XP with you as do through the book over time. Today:

The Seven Myths of Pair Programming

1. It will double the workload with two doing the work one can do

In fact it lowers it. Two can produce a better quality code in less time and less time is spent debugging later as well. Need to say more?


2. I'll never get to work alone. I couldn't stand that!

Nonsense! You'll never spend 100% time pair programming a day. In most cases the "alone time" ranges from 25% to 50% a day. Pair programming is intense. We need to have breaks from pairing. During those we get to do stuff that you got to do, but it'd be a waste of time if done in pairs - like checking and responding to your e-mails. If you want to do some programming alone, then pick something simple. Leave the heavy stuff for pair programming.


3. It will work well only width the right partner

Again, we think that there is the "right" partner, but as we realize that we all are different and work differently, we can influence each other in many ways. Thanks to pair programming I got closer to many people in the team and feel more comfortable working with them. I feel being part of the team. Pair programming enhances the feeling of trust and improves the teamwork.


4. Pair programming is good for training. But, once you know what you're doing, it's a waste of time

Not necessarily true. It's a great way for knowledge transfer. I started working on my current project much later than my peers. Pair programming with them gave me a real boost in getting my head around the application and frameworks used. Pair programming can be looked at as never ending learning where we all learn from one another, not necessarily realizing the teaching part.


5. I'll never get credit for doing anything I'll have to share all recognition with my partner

Who cares! This is teamwork, forget your ego! Thanks to pair programming I feel stupid every day. In a good way, that is. I know I learnt a lot and I did a good job every day. You know how much you learnt and your partner will tell you if you did a great job. Don't be shy, do the same for him/her. Besides, you can develop an approach of task ownership. You pick and own the task. Then you "recruit" a partner to pair on that task with. Still there is no code ownership and you can get credit for the task well managed and done.


6. The navigator fins only syntax mistakes. How boring is that! Compilers can do that better than humans can any way

Navigator usually has the time to focus on the problem on a larger scale or consider various cases or scenarios while the driver works and concentrates on the particular one the pair is solving. This approach shortens the time - one, after finishing a step, would have to stop and think about the next step before continuing. Two, on the other hand, can work in a "flow" and maintain a steady pace.


7. The only time I ever get any real work done is when I'm alone. Now, Ill never get anything done! Pair programming would drive me crazy!

Well, pair programming is a different way. You can't get into the "flow" as described in Peopleware : Productive Projects and Teams written by Tom Demarco and Timothy Lister. But on the brighter side, if you develop in pair it does not take you 15 minutes to get back to the "pair flow" when interrupted. Plus, when people see you are busy, they are less likely to interrupt you anyway.

Pair programming has only one drawback for me so far. I don't get to listen to my MP3 collection that much, well almost at all. All that joy is left for my little home projects I work on just by myself.

Simplicity and XP

I like simple things. Why bother with making something complex if the simple thing works. This reminds me of the story, where NASA spent one billion dollars inventing a pen that would work in space while Russians simply used the pencil. Read more about The billion-dollar space pen myth.

Simplicity is one of the four values of Extreme Programming.

Ken Auer and Roy Miller when defining simplicity in their book Extreme Programming Applied - Playing to win, refer to the original definition by Kent Beck in Extreme Programming Explained; the simple design:

• runs all the tests
• contains no duplicate code
• states the programmers' intent for all code clearly
• contains the fewest possible classes and methods

When speaking of the simplest design, remember that finding the simplest design can be the hardest thing. But it is worth, as once found the design will be so obvious that you will wonder why it took you so long :-)

So, the moral of this short blog of mine is: stick to KISS! (keep it simple, stupid!)

Java Puzzlers

I have been working with Java since 1997 and after all that time I thought I new Java. I also managed to earn few Java certifications. So I was quite confident I could cut good code that would run as expected.

That was until I read Java Puzzlers written by Joshua Bloch and Neal Gafter. Boy, I was wrong! There were so many examples of Java code that I expected to produce different results. I strongly recommend reading this book. It will give you an insight into the core of Java classes, objects, primitive types, libraries, and more...

Contents: Introduction Expressive Puzzlers Puzzlers with Character Loopy Puzzlers Exceptional Puzzlers Classy Puzzlers Library Puzzlers Classier Puzzlers More Library Puzzlers Advanced Puzzlers Catalog of Traps and Pitfalls Notes on the Illusions References Index

Serious geek fun!

Moreover I recently visited Javalobby website and found an interactive Yet More Java Puzzlers talk slideshow that illustrates eight more Java puzzlers that were presented on JavaPolis 2005 conference.

If you don't have the book yet, have a look at the free Sample Chapter
or Yet More Java Puzzlers for a hint of Java flavour. It's goof fun, plus you learn something from it.