~pperalta

At the SD East conference a few weeks ago they were giving away stacks of magazines. One of them was Better Software, a magazine dedicated to software quality. One of the articles was “Tapping into Testing Nirvana” by Tod Golding. He writes about his experience with TDD. As many of us that have adopted TDD, he was quite enthusiastic at the beginning, especially as the quality of his software improved. After a while however he noticed that the tests were getting more and more difficult to maintain. As Kent Beck says in Test-Driven Development by Example,

“Test driven development is a way of managing fear during programming.”

That turned out to be the exact opposite of Tod’s experience. He writes,

“Every time I wanted to tweak my code, I found myself worrying about how many tests I’d have to rewrite or simply throw away. I felt like I was continually building and destroying my suite of tests. I expected this at some level, but it still seemed like far too many of my tests were coming and going.”

He comes to the realization that code smells can happen in test code just as easily as production code. For those that are new to TDD, writing a test is simply a means to an end: the working code. Most of the TDD examples that one encounters concentrate on the xUnit testing APIs and techniques (such as mock objects.) However, to realize the full benefit of TDD the test code has to be maintained as much as the production code.

This, of course, led me to the real epiphany. I realized that those extracting the most value from their tests were treating them with much more reverence than me. While I always viewed my tests as shallow, one dimensional dolts that could be thrown away at any second, other developers were treating their tests like first-class citizens.

I am certainly guilty of viewing tests as shallow. My biggest sin in this arena is copy and paste unit testing. When I’m testing a method multiple times with different sets of parameters and conditions, the quick fix is to just copy an existing test method, make a few tweaks and rename the method. This of course makes the test class quite difficult to read and maintain. When changes get made to the production method, all of a sudden a bunch of test methods have to change.

As I looked more closely at their tests, I discovered that the best unit testers were applying all the same values to their unit testing as they were in their own implementation. They were abstracting out concepts, building object hierarchies, leveraging polymorphism, limiting coupling, and so in. In essence, their test code and their application’s code were on equal footing.

This view, in my opinion, represents the next step in TDD. Most people that have been on the JUnit website are familiar with the term “Test Infected”. This is the point where developers realize the immense value of a complete test suite and thus start to write unit tests. Next comes the practice of writing tests before code. Once the tests are being written before code, the next step is to view the unit tests as “first class citizens” and to apply the same concepts of clean code to the suite as to the production code.

Here’s another “me too” congratulatory posting to I21 for the release of Spring 2.0. Keith Donald posted an entry to TSS describing all of the new features. I look forward to trying out the AspectJ integration, the asynchronous TaskExecutor classes, and the custom XML configurations for the bean factory.

In his ORM session today, Scott Ambler talked about the impedance mismatch between databases and objects. The technical mismatch is a well known and studied issue. However, he spent quite a bit of time discussing the mismatch between the object and database communities. In particular he addressed the manner in which data people work, which is usually BDUF as opposed to the evolutionary iterative approach that is preferred by object people. As the author of Agile Database Techniques and Refactoring Databases, it is not hard to tell which position Scott takes. However, he does acknowledge that traditional data/DBA types have knowledge and experience that is vital to effective high performance databases. These are skills that OO developers don’t necessarily have. At the same time, data people tend to only view data on its own instead of how it will be used in a real world OO system. He argues that both communities need to work together and to learn a bit about the other’s discipline in order to develop the best applications possible.

He goes on to describe basic ORM techniques, such as how to map inheritance, associations, collections, and so on. The content of the presentation is available on the Agile Data web site.

In the first talk that I attended today, Uncle Bob makes a convincing argument that time constraints are not an excuse for sloppy coding. His claim is that bad code has a “more profound and long-term degrading effect” than anything else, including bad schedules, requirements, and even team dynamics. He states that coding clean will actually speed up development, especially when you have to go back and make changes. The code sample that he presented was a condensed version of this article that he wrote about a command line argument parser. He starts out by writing code to parse boolean arguments, but his initial design ends up not scaling very well when he adds processing of integer and string arguments. We saw lots of if/then/else statements that were doing type checking. When you see this in an OO language, that’s a good sign that an object hierarchy is in order. The slides show him adding a hierarchy to replace the if/then/else statements with polymorphism, along with some other code cleanup. Here are some tips that he passed along:

• Write code (and tests) in tiny increments.
• Functions should be small. He asked the audience how big a method should be, and an audience member suggested that it should fit within your screen. That would have been my answer as well, but he pointed out that screens are so large (and high res) today that this old rule of thumb doesn’t apply anymore. The limit should be about 20 lines or so.
• A method name should describe exactly what the method does. If you have to browse to the method to figure out what it’s doing, that may be a bad sign.
• Use the Command Query Separation principle. Methods that return a value should not change state, and methods that return void should be used for changing state.

Both in this talk and the Compleat Agile developer, he talks about the allure and dangers of complete rewrites as a remedy for ugly code bases. This is a topic that I have read about before from Joel. In addition to all of the reasons that Joel gives, Uncle Bob provides another one. He has seen elite groups formed in many places to rewrite software only to discover that they cannot keep up with the legacy systems that are still being maintained. Eventually the new system becomes just as much of a mess as the old system. The team tasked with the redesign starts to loose members. Before long, developers are demanding that the new system be redesigned yet again!

Ken Pugh of Pugh-Killeen Associates presented guidelines for creating interfaces:

• An interface implementation shall do what its method says it does. This principle was also mentioned in the clean code talk.
• An interface implementation shall do no harm. This means no nasty side effects, such as memory leaks, etc.
• If an implementation is unable to perform its responsibilities, it shall notify its caller and report an error in the user’s terms, not the implementation terms. This one is important because many times methods will throw internal exceptions that the caller has no idea what to do with.

Tomorrow I’ll get to see Scott Ambler talk about ORM.

Today is a brisk fall day here in Boston where the SD East Best Practices conference is getting started. The first day consists of half day tutorials, one before lunch and one after.

The morning tutorial that I attended was presented by Luke Hohmann of Enthiosys. The topic was “Innovation Games: Creating Breakthrough Products Through Collaborative Play.” The focus of this talk was strategies that can be used to solicit customer input and how to process this data to turn it into innovative products. The techniques consist of games that can be played with small groups of customers in order to understand their wants, needs, and priorities. They have an entire catalogue of games that can be used for various purposes and audiences. During this presentation he went through three of them: Speedboat, Buy A Feature, and Spider Web. The game that I found the most interesting was Buy A Feature. Each customer is given a certain amount of play money and a list of features along with their cost. The customers then get together and decide which features they would like to “buy.” Sometimes features are expensive and a single customer does not have enough to purchase the feature, thus they must collaborate and pool their money together to get what they want. I like this game because it demonstrates the constraints (especially time constraints) that developers have, but it puts control of what goes into the product in the customer’s hands.

After lunch it was “Principles of Object Oriented Component Design” with Robert C. Martin, AKA Uncle Bob. The theme was software complexity and how OO design can make software simpler to write and maintain. OO systems that have modules that have cyclical highly coupled dependencies are very difficult to modify. Changes made to one part of the system can affect other parts of the system that are not related. Thus, Robert describes how to build systems that are loosely coupled by actively managing dependencies across modules. In practice this is harder than it sounds because all it takes is one wrong import statement (or the wrong #include) to create a cyclical dependency. (For the purpose of this talk, the definition of a component is an isolated binary that can be deployed independently, such as a jar file or a dll.) With Java, JDepend can be used to avoid this problem. Dependencies should always flow in one direction across modules; in other words module A must never depend on module B. Sometimes this cannot be avoided, so a few techniques can be used to avoid a bad dependency:

• Copy and paste the code from module A to B. Hint, this is not the best option.
• Refactor the functionality to a module C, and have both A and B depend on it.
• Express the functionality that B needs from A as an interface. Define that interface in module B, but have the implementation injected from module A.

It would be nearly impossible to determine up front exactly which modules should exist and what their dependencies should be. For this reason, he advocates a design that evolves over time, which is the Agile approach. As I pointed out to him, skills in test driven development and refactoring are absolutely crucial in order to develop in this fashion. Without the ability (not to mention the tools that IDEs provide) to refactor, developers will be reluctant to shift code around that already works. TDD is the tool that gives developers the confidence to restructure and move code around because that is how they know that nothing was broken in the process. Although he did mention using interfaces quite a bit in the talk, I think that interfaces play a huge role in loosely coupled classes and modules. I think this point could have been emphasized more, but then again maybe it would not have been necessary for the target audience.

Tomorrow morning is his talk on Clean Code:

This class is about code. We will put code on the screen and we will read it and critique it. And then, one tiny step at a time, we will clean it. In this class, you will participate in the step-by-step improvement of a module. You will see the techniques of the Prime Directive (Never Be Blocked) and Agile Design principles brought into play. You will witness the decision-making process that agile developers employ to write code that is expressive, flexible and clean.

Conferences don’t usually go this deeply into coding, so I’m looking forward to this talk!

Here are more pictures at the conference.