8th Light Blog: Tag Paul

Apprenticeship month one report

Paul Pagel — Tue, 01 Jul 2008 01:14:00 +0000

8th Light has an apprenticeship program whereby an 8th Light craftsman will mentor an individual for three months. During that time, the craftsperson becomes responsible for a single apprentice. I am one month into a mentorship with an apprentice. This blog is about observations I have made about myself as a mentor.

Curiosity

He asks me questions that I wouldn’t ask myself. I had him do an exercise about Law of Demeter , to find Law of Demeter violations in my code base. He found something like:

Law of Demeter

“Ted Williams”.to_s.strip.upcase

He was counting the periods, which is what I explained is often good measurement of Law of Demeter violations. Yet this is not a Law of Demeter violation. Each one of those methods returns itself (a string) in a changed state. It is not a string of implementation details- this example is just changing a single object. The pivotal piece of information is that all of these methods on string return the string itself. Also, is anything inside of Ruby core language capable of Law of Demeter? It is unlikely to change, and is there a problem being coupled tightly to your language?

I sometimes get desensitized to the original premises of good development. When I first learn something, I remember the example of the rule more than the value of the rule. The value of learning about Demeter is rooted in encapsulating logic in such a way to hide implementations from an object’s clients. When I first learned about Demeter, all I could do was point out violations. The more I developed, the more it was internalized as a guide for a higher development idea. I want to keep my modules as decoupled as possible. However, that notion only came with development experience. Now I don’t think in terms of violations or non-violations of Demeter when I read a piece of code. It is just ingrained in my developmental context that I should develop my modules in such a way that they are autonomous. This weeds out most Law of Demeter violations by itself. Bringing these premises back up in my development as a craftsman gets my curiosity started. Like a good song or piece of writing, every time I come back to it, I take something different from it, because I am in a state of constant change.

Teaching

Sometimes I forget how important teaching is to the craftsmanship model, because I am still an extreme novice at it. It is one of the steps involved with internalizing development skills. When I pair with my mentor, I am constantly amazed at how he skips steps in the development rational process. Instead of following a linear thought pattern to a solution, it seems there is a giant shortcut in the rational processes I go through. That gap is a lookup table of solutions in his head. It appears so easy and effortless. Teaching is part of a formula that has given him a development context that is superior to mine. The more I am able to teach, the more I internalize the ideas about development.

There is a baseball story from about a year ago. Greg Maddux was warming up before a game and his catcher exclaimed to the pitching coach, “I bet I could catch him with my eyes closed.” Well, after much effort, they convinced Maddux to give it a shot. The catcher was going to call his pitch, then close his eyes. When the ball was about to hit his mitt, the pitching coach with his eyes open was going to yell “now”, whereupon the catcher would squeeze his glove on the ball. Well, on the third try, the catcher caught the ball. The degree of difficulty of the exercise is incredible, but Greg Maddux had spent so many years internalizing the mechanics of his craft that he could effortlessly hit the catcher’s mitt. There probably are only a few pitchers in the long history of baseball who could match that exercise. I am not anywhere near that kind of skill in development, but that is my goal. When you get the mechanics of your craft to be intuition, it frees your mind to think about and solve larger problems. I have been fortunate to spend time with enough great developers to see this mastery in action.

Communication

For me, what is special about teaching is the commitment of thoughts to sound. Forcing something outside of my internal monologue always changes it, even if it is a small change. When I explain something, I often have to explain it multiple ways (this is telling of my communication skills, not of my apprentice’s learning skills). So, the more I am forced to answer questions on the spot, the better I get at quickly thinking through a question and giving a good answer. This dialogue is another one of the mental exercises which translates into my everyday development. It makes me a better pair programmer, better presenter, and better writer. Being able to accurately explain a problem and a solution using the language of software development is a very important tool in being a successful craftsman, and a tool that I fight uphill to improve upon. When I go to a talk at a conference and the presenter hits the problem and solution perfectly, it is a wonderful experience. The same is true when a team member can explain a solution in such intuitive terms that everyone gets it immediately.

Apprenticeship for me is as much about internalizing and expanding my own skill set as it is about expanding my apprentice’s.

Developing against web browser navigation

Paul Pagel — Fri, 27 Jun 2008 15:07:00 +0000

I find while writing web applications that I end up redefining what it means to go “back.” This means where I want the user to go when they hit the back button. The creation of AJAX has killed the behavior of the navigation buttons in the browser. The navigation buttons on a browser are from the time of sundials and static web pages. We live in the world of atomic watches and dynamic content. I don’t want you to go back to the last static web page that was loaded. More times than not, that messes up the user’s experience.

I have seen/implemented some solutions. One that we have used is when the first page is served up you start some kind of memory. Start a stack of the user’s actions, saving them in the session. When the user tries to go back to the main page, they are redirected to the real last page they were at. This is good for AJAX intensive applications. These days I am finding the percentage of AJAX requests is many times higher than AJAX requests when I am trying to create a rich user experience. The problem is you get into situations where the user really does want to go back to the last domain they are at, but your application, very annoyingly, will not let them leave. As a user of the internet, I quickly learned that if I hit the back button many times quick enough, the page doesn’t have time to render the redirect, and I can get back. The fact I even know that is annoying, let alone what it takes away from my application.

Another solution is to have lots of static pages. Don’t let the user get too far without loading a new page. This way the back button can really only do minimal damage. Use lots of client side JavaScript and limit the amount of AJAX calls to the bare minimum. This has become industry standard for web pages which involve payment processing. Since the developers can’t guarantee that a user won’t hit the back refresh / or forward buttons, you have to be able to have some kind of state recovery. If the distance between static pages is short, then you don’t do too much damage. However, this constraint limits what you can do with your web application, limiting AJAX calls.

My favorite solution is to take the browsers out back and teach them about feature envy. They are telling me to serve HTML/JavaScript/Flash content inside their main pane architecture, and they will take care of the rest. Well then, keep your hands to yourself!!! Navigating between web applications(domains) makes sense at some high level, because that is in the job of a web browser. They get you from one web application to another. However, inside of my web application, let me decide what I want the back button to do. I understand some kind of backwards compatibility so the Geocities web page with the contra code on it doesn’t get lost (like we don’t all have it memorized). So, let me turn it off for my domain. Give me a JavaScript API to say what the back button behavior should be or let me at least turn it off. There are some attempts to do just this, but they are not straightforward or part of the core library.

So, this will require all developers of web applications to implement navigation that makes sense within their web applications. Great!!! If they are worried at all about user experience, they have already thought about this and have some solution in place. Getting rid of the back button just gives them more power. I have never met a developer who wouldn’t embrace more freedom in their tools.

Some Thoughts On Software Defects

Paul Pagel — Tue, 24 Jun 2008 06:13:00 +0000

Software defects are a part of software. This is a negative subject, but I don’t want to seem like the software I write is full of defects and bugs. This blog is addressing how I have seen teams turn a roadblock into a success. I have read and heard at conferences about teams who take small failures and create a culture of failure around it. Following are some examples of small failures I have seen and great successes built around them. Sometimes I see small failures as a path to larger positive culture changes.

I think it is safe to say all software that is used and sufficiently complex has defects. There are many reasons for the defects. Here are a few of the defect situations I have been in and how our team solved them.

I think the important part I learned after evaluating these is that resolution of these situation needs to be fast and high quality. They need to make the project better off at the end of their resolution. Success for the customer is the only true result of a project, and defects may not be the most ideal path, but they must lead there.

The speed is important, but it doesn’t mean I should rush a solution and throw it in as soon as possible. To me it means giving the defect the red carpet treatment. I am trying to capture craftsmanship in the face of adversity. Every project has its ups and its downs, and a craftsman will take pride in success through any obstacles. Instead of making defects a slippery slope downhill, they are one step back and we take two steps forward.

Bugs

Bugs are a part of every piece of software I have written. That statement sounds a lot worse than it is. I have worked on systems where the requirements are dramatically changed week to week (which can be pretty exciting). There are situations I didn’t take into account, or some behavior I didn’t imagine until a real user started hitting the system. Now, as a developer, I do more mental exercises and think thoroughly through my solutions as I get more experience. This has never made my code bug free. For that reason, my team needs to know how to deal with bugs (I am fairly certain I am not the only creator of bugs).

Here is a line from the Pragmatic Programmer book, “It doesn’t matter whether the bug is your fault or someone else’s. It is still your problem.”

So, the team has a bug list. We list out the bugs as a todo list in basecamp, so they are not so formal they can be forgotten about. Then we try to address them and work on new stories. This worked well enough until there was a big release coming up and our customer came back to us with a big list of bugs. We put them on the list and continued to fix them, as well as work on stories. They were getting completed, but there was never an empty bug list. Then, the customer (who can directly add/edit the bug list) started writing priorities to the bugs. This one is HIGH priority. This one is CRITICAL. This one is IMMEDIATE. I make the suggestion “We need some real tool to manage our bug list,” because I can’t fit all this in my head. There isn’t that much room up there and I need to use it wisely. One of my team members suggested maybe it wasn’t the craftsmanship way to have ANY bugs shipped. I was trying to solve the wrong end of the equation. So, the team lead put forth a no bugs policy that we all agreed with.

You can not pick up a new story unless the bug list is empty.

This made sense to me, but I had reservations about a small/insignificant bug taking priority over a story that is important. To date, this has not happened, and the bug list has stayed near no bugs. That doesn’t mean less bugs are found, it just means they are fixed, and the code is refactored to prevent a future occurrence. Most importantly, some tool to track bugs never made it into our system. That was an idea which would have desensitized the team mentality to bugs, whereas with our policy now we are very sensitive to the issue of bugs. Challenging the craftsmanship of the team members that buggy code is something you should take personally was the right choice. Bugs got a first class ticket to termination in our system.

Now, the definition of a bug versus a small feature enhancement is a fine line. I know I have failed to define it well, and that might contribute to what gets called a “bug”. Often times, the urgency in the customer takes up more mental space than me thinking through it, looking up the acceptance criteria for the story where it was implemented, and going back to the customer and saying, “No, that was clearly not a defined scenario, we are going to need a story to turn that button green.” Now the next time, it is more than turning a button green, but the precedent has already been set. All I have been able to do is to strike a balance based upon how much effort it would take to make the bug/feature enhancement work. If it is a lot of effort, I will double check the bug to make sure it is a bug. If it is, I fix it. If not, I will push back to the customer to write a story card.

Production Support

Once a system goes into production, support begins. Following along with one of Paul Graham’s ideas, we have the developers doing the production support. We are the ones who wrote the system and know the system the best. When I look at a production support request, I can not only solve it, but make sure it doesn’t happen again. Or if it does, make sure it is easy to correct.

So, during our first deployment of a system, a single team member stepped up as the “production support” developer. I don’t know if he embraced it or was cornered to it, but as a craftsman, he took the responsibility and ran with it. As further systems were released, he would sometimes be doing an entire day of production support. Production support can be a lot of debugging and fixing data, which can be fun, but more times than not is tedious and rhythmic. Often times when I saw a production support email, I would look to the “production support guy,” who could fix it in about half the time I could. This seems a lot like a silo to me. Everyone should be able to do production support on any system. I should have to, because it is a perspective of the system that is important to have.

In response to this, we came up with a system of triage. Each day of the week is assigned to a specific developer. If a support item comes up, it is the job of the triage developer to respond to the client/customer we are working on it. If it addressed to a specific person, they will inform them. Otherwise it is on the triage developer’s shoulders to fix the support request before they continue their work for the day. This ensures the client always has an open line of communication with a developer. An email never slips through and doesn’t get addressed. There is clear responsibility to who should be addressing the support item. I know the “production support” developer is in favor of this system. As well as the customer, they ask who the triage is for the day and have no qualms about interrupting their work, as they should.

Communication and Managing Expectations

Recently, I did some integration work with a third party vendor. They were developing their side of the integration at the same time as us. Not wanting to slow development and wait for their functionality, we decided to write a mock server and integrate with the host according to the spec from the third party vendor. We received a story from the customer for that and proceeded to make the client for the third party system calls. We finished our story. In the demo portion of the iteration planning meeting, we could only demo against our mock server. This caused some nervousness in the customer (rightly so). I replied, “Once their side of the system is done, we should be able to send our calls across.” Then we received three more similar stories, but different system calls. We did them, removed the duplication and felt really good about the job we did. The came their test server.

Nothing worked! There were all sorts of communication problems, questions about who implemented the system to what spec, and political questions. Despite us thinking we were in the right, the stories were signed and the customer said, “Well, you said this would work.” At first, I tried to communicate the reason why it didn’t work, and how we can move forward. We came to spend a lot of time on this, and the team felt the integration should be its own story. The customer pushed back, “Well, you said this would work.” There was some tension, because both sides were right. We didn’t believe it was our fault it didn’t work (neither did the customer), but we told them it would. Rather than let out the righteous indignation I was feeling, one of the team members mentioned.

“We should not have assured you it would work.”

That one line brought the real problem to the front for both sides. We didn’t know whether it would work or not, just that we wrote the right code to the specification we had at the time. That code by itself has no value to the customer without it working, though. Once that line was said, everyone in the room sat for a second, then understood. The expectation over defect versus behavior was out of sync. A little ownership over the defect was all we needed to ease the tension and move forward. It is unproductive to get stuck in a stalemate of expectations. When in doubt, the customer is always right.

Active Record migration dependencies

Paul Pagel — Sat, 14 Jun 2008 02:38:00 +0000

We had a new developer join our project recently, and he needed his computer to be setup with the project. “Here is the svn repository, when you check it out, run these rake tasks.” It unfortunately, is never that easy. This project setup revealed something about Active Record and migrations that I didn’t know about.

When I create a migration, I will often do data manipulation on the database, or pre-populate some fields with data needed for a lookup table. Lets look at a sample migration from a trivia game.

class CreateQuestions < ActiveRecord::Migration

  def self.up

    create_table :questions do |t|
      t.column :text, :string
      t.column :answer, :string
      t.timestamps
    end

    Question.populate
  end

  def self.down
    drop_table :questions
  end
end

I want to add some sample questions, so that even if you don’t have your own questions, you will still be able to play the game. I added the method to the populate model, because I use it elsewhere in the code, and I try to keep it DRY. The populate method on the question model looks like this:


class Question < ActiveRecord::Base
  belongs_to :game
  has_many :answers

  def self.populate
    Questions.create(:name => "What is your favorite color?", :answer => "I don't know")
    Questions.create(:name => "Who was the first President", :answer => "George Washington")
    Questions.create(:name => "Who was born Samuel Clemens?", :answer => "Mark Twain")
  end

end

So, later on, I decided to add a degree of difficulty to the questions, so the players can get more points for answering harder questions. Here is what the migration looked like.

class CreateQuestions < ActiveRecord::Migration

  def self.up
    add_column :questions, :rank, :integer
    Question.destroy_all #In case there are any old ones
    Question.populate
  end

  def self.down
    remove_column :questions, :rank
  end
end

Of which I had to change the populate method on the question class to:

class Question < ActiveRecord::Base
  belongs_to :game
  has_many :answers

  def self.populate
    Questions.create(:name => "What is your favorite color?", :answer => "I don't know", :rank => 1)
    Questions.create(:name => "Who was the first President", :answer => "George Washington", :rank => 3)
    Questions.create(:name => "Who was born Samuel Clemens?", :answer => "Mark Twain", :rank => 8)
  end

end

Then I ran my migrations, and continued development. Then when developer number 2 came across and checked out the project and ran the migrations, he got the error.

undefined method rank= for class Question (…or something very similar)

The problem is the old migration is dependent on the new model. All models in rails are just a mirror of the database, so the new model has a forward definition of the data. The code in the model knows about the rank field, but the schema of the database hasn’t caught up to create that portion of the mirror yet. This creates a little bit of a catch 22. The rails wiki (http://wiki.rubyonrails.org/rails/pages/UsingMigrations) about migrations tells you to redefine the class to stop name conflicts. This would require me to make my migrations model agnostic, inserting straight to the database. As a spoiled brat when it comes to databases and rails, I refuse to let go of my Active Record sugary syntax. Another solution I thought of is to just make the last change to question do the populate, and remove it from the previous versions. This will become a maintenance nightmare.

I came to the realization that I want to make a distinction between form and content when it comes to migrations. Form in this case is schema form, the changes to the database which reflect the data which the Active Records can potential hold. Content is the specific data which is in the database. This distinction allows for me to use the power of my model classes in my data migrations, which is the place it is useful. It maintains backwards compatibility, because before I go touching the data, I have to make sure my schema is right.

What does this look like in Rails? I am not sure yet. Possibly db/migrations/schema and db/migrations/data. Possible saving the data migrations in each migration as a block and executing those at the end, only when you have the schema is correct. I am going to try it out!

Code Less: A Language Keystroke Expirement

Paul Pagel — Sun, 08 Jun 2008 18:06:00 +0000

When I first started writing code in ruby, it was a breath of fresh air after writing C# code for a year. Ruby had a thesis, a clear purpose, rather than a hodgepodge of features strung together. It was a language obviously written by someone who cared about what the code looked like. So I jumped into it and loved writing ruby code (still do!). Recently I had to write a project in Java using IntelliJ, and the powerful IDE was also a breath of fresh air after using text editors to write ruby code. The IDE helps me in the same way ruby helped me. I write less code that does the same thing, without loosing expressiveness or transparency of intent. Less code in this case meaning less keystrokes.

So, I am going to do a little experiment using two editors and languages: ruby with textmate and java with IntelliJ. I want to see how many lines of code I have to write. The application I am going to start is a simple baseball at bat scorer. First lets see the ruby version.

We have about 27 lines of code written, and other than the describe method, which I have a macro for, I typed them all by hand. Lets look at the java code. This is just the JUnit test I wrote, there is no production code yet.

It is about 16 lines of code, which I wrote all of but the import statement. By doing a few alt-enters on the squiggly lines, I can get a stub of a class looking like this.

That is 13 more lines of code, without really typing, just hitting enter a few times. Now, lets start to make the method pass. I am going to write the algorithm without worrying about all the type definition java wants. Here is what it looks like.

So the code written is around 4 lines of code. Lets use the IntelliJ autocomplete features to help us make a passing test, which looks like.

So roughly, the ruby version was 23 lines of written code and the java version was about 20 lines of written code. There is an expense to doing all of the alt-enters to auto-generate the method and variable stubs, but IntelliJ is pretty smart about what it generates. Also, I understand a single test doesn’t tell the whole story, but it is a good indication. I found as I wrote more tests for this application, a smaller amount of keystrokes was needed for the java version, and the same amount was needed for ruby. This is due to the refactoring tools, and intellisense. As applications get larger, I find the IntelliJ refactorings become more useful. Inversely, ruby refactorings become more painful, as they are mostly done by hand.

So, in the end the constraints on a static language allows the IDE to make the refactoring tools better. Specifically, when writing java code, I can lean on the IDE to generate all the uninteresting stubs for me. All I do is fill in the algorithms: the fun part. When I start to see places where my code can be cleaned up a bit, I can lean on the IDE again to do those refactorings for me once I recognize the need for them. Removing and optimizing the code is something which is easily deducible in static languages, as it is mostly pattern matching, with no monkey patches, meta-programming, and evals to worry about. This is a limitation which frustrates me as a developer who wants to have a large set of tools in my bag, but is helpful when it comes to developing a powerful IDE.

The number of lines of code I need to type isn’t the reason I choose a language over another. In fact, it would be pretty low on the list of deciding factors. However, it is interesting to see what each language and its sets of tools do best. Hopefully the ruby community can take some notes from them. I would rather solve the other end of the equation, get a powerful ruby IDE. I know Eclipse and Net Beans have some preliminary refactoring tools, but they are still aways from being as seamless as their java counterparts.

Wake up and code!

Paul Pagel — Fri, 09 May 2008 00:34:00 +0000

The other day, I was with my team at an interview for an internship. After we had asked the candidate some questions, he started to reciprocate, asking each one of us a little about our development past. Every one of the developers stories went something like, I was at the wrong job, and had to get out. The candidate listened carefully to each story, sat for a minute, then asked the obvious perfect question, “What makes the right job?”

I heard responses like “Waking up in the morning and being excited to work, rather than counting the days until the weekend.” The reason this struck me as interesting was only when I reflected back to why I loved computers and programming in the beginning. It was all about the problem. I went to college, so I could join the CIA or some think tank which wrote software which monitored and defeated the enemies entire world. About every developer I went to college with got into computer science with some similar grandiose notion. Most of them were gamers that wanted to work on the next big game. Yet today, I know no developer who works on games, and I don’t work for a think tank. I know lots of developers who are more than qualified to do it, but choose not to. So, how does this relate to the right job question?

The answers about the right job question had nothing to do with the problem set being solved either. Nothing to do with WHAT applications were being written, but the culture and with whom they are being written. I think this is because each problem set worth application development proposes unique and interesting problems for a developer to solve. I have never been on a project which didn’t constantly keep me on my toes as far as problems to be solved. Even if the business domain is a bit bland, the development domain isn’t. I have seen developers to do lists get bigger and bigger from day one on a project, and never shrink. This has nothing to do with laziness, quite the opposite, it has to do with an insatiable drive to make things better than they are.

As a developer, my problem set isn’t the business/science problems I am solving, even though that might be interesting in itself. My problem set is development itself, the different patterns/practices I use to solve the world’s [software] problems. It is like many art forms where the beauty and creativity exists in the process of creation rather than the results. I am sure you could have asked Pablo Picasso to paint something he didn’t have any interest in, and he would have been passionate about it and done a wonderful job. I suspect it is because the importance is in the painting process and the choices you make during each step. How he chooses to depict the subject is more interesting more than the nature of the subject itself. I find the same true in development. The thought that goes into the different development choices I make on a daily basis is the part that drives me to love development.

Having the right results is only part of the equation (an essential part though). When I started my path as a developer craftsman, I learned the WHAT in applications is not as important as all the other variables. I suspect some of the other members on my team would agree, based on their answers to the right job question. Being part of a company that values the software for its own ends and spends the time and attention to do it right is a privilege to me. To me, that is the definition of the right job. I enjoy knowing my software will be used. Everything I write is valuable to the company for its longevity and success. It takes people who are similar in values for it to work, but it makes the work fun. It makes me wake up before my alarm, rather than snoozing.

Ruby and the Art of Computer Programming

Paul Pagel — Tue, 06 Nov 2007 15:09:00 +0000

Recently, I started to read the Knuth’s Art of Computer Science. To spice up the exercises, I am writing them out in ruby. Thinking about the basic math of programming and how to implement it in a high level language like ruby has been fun. The evolution of programming languages has gone far since the book was written. We can use cool new ruby syntax to do multiple steps in an algorithm!

Also, this is an exercise in writing clean code. Some of the algorithms in the book are a bit hard to read in there pure math form. So, when I write them out in ruby, I try to use as much expressiveness without adding clutter. This is no easy task, and often times I have to walk away from an algorithm for awhile and come back to it, because I will have my head deep in the math and less in the code. Or vice versa.

I was showing one of my solutions to a colleague of mine, Doug Bradbury, who saw a better way in ruby to solve the same problem I was with less lines of code and a higher readability. So, I decided to share one of the problems, and in a few days, I will post my version of the solution. We can see different solutions in different languages and different styles. Go ahead and try it out.

Here is the algorithm as written in the book.

This is Euclid’s Algorithm for the greatest common divisor

E0 [Ensure m >= n.] If m < n, exchange m <--> n. E1 [Find remainder.] Divide m by n and let r be the remainder. (We will have 0 <= r < n.) E2 [Is it zero?] If r = 0, the algorithm terminates;n is the answer. E3 [Reduce.] Set m <- n, n <- r, and go back to step E1.

UPDATE: Here is a solution


def are_whole_numbers?(*numbers)
  numbers.each {|number| return false if number.to_i.to_f != number}
  return true
end

def euclid(m, n)
  raise "Must be whole numbers." unless are_whole_numbers?(m, n)
  return euclid(n, m) if m < n

  remainder = m % n

  return n if remainder == 0
  return euclid(n, remainder)
end

#Here are some examples
puts euclid(35.0, 40.0) #should be 17.0
puts euclid(119.0, 544.0) #should be 17.0
puts euclid(555.0, 666.0) #should be 111.0

Self Shunt

Paul Pagel — Mon, 11 Sep 2006 16:06:00 +0000

The self-shunt method of testing has been conflicting for me. Self-shunt is a good testing pattern to test observers/views. A colleague of mine has started to convince me that self-shunt has some serious drawbacks. I want to explore the different ways to address the same pattern and how they fit into the test process and the test content. Are certain patterns easier to write and certain ones have a better final form?

Lets look at some code from Michael Feathers self shunt paper (see bottom for link). I extended it to do the mocking examples. The user story we are working with is the name of an item must be displayed on the led when the item is scanned.

Writing all of the tests did not require a concrete window (Display). We didnâ€™t need to create the stub of the file to use; we could just use the interface. All the test patterns let the test be isolated in the test class/interface/production class triad. As a developer, it is easier for me to produce faster without quality loss if my context of thought is limited as much to the scope of the test as possible. Each extra window I switch is more contexts to deal with.

Here are three different tests:

public class ScannerTest extends TestCase implements Display
{
    private Item lastItem;

    public void testScan()
    {
        Item item = new Item("corn flakes");
        Scanner scanner = new Scanner(this);
        scanner.scan(item);
        assertEquals(item,lastItem);
    }

    public void displayItem(Item item)
    {
        lastItem = item;
    }
}

The first test is making user of self-shunt test. Self-shunt was a quick way to start writing a test. The implementation on the interface in the test class will give you a good idea on what the implementation of the concrete class should look like when you get there. Also, the test is simple and the syntax is expressive. However, the scalability is questionable. If you had more than one self-shunted interface in a single test file, it would be hard to start differentiating between which variables are used in which. Also, moving around the file to get a good sense of what a test is doing is misdirectional and distracting. Ideally, I want to see the entire test on one screen, so I can read it. If there were many implemented methods in a test file that were not tests or helpers, there is the potential to be confused.

public class ScannerTest   extends TestCase
{
    public void testScan()
    {
        Item item = new Item("corn flakes");
        Display mockDisplay = new MockDisplay();
        Scanner scanner = new Scanner(mockDisplay);
        scanner.scan(item);
        assertEquals(item,((MockDisplay)mockDisplay).lastItem);
    }
}

public class MockDisplay implements Display
{
    public Item lastItem;
    public void displayItem(Item item)
    {
        lastItem = item;
    }
}

Then I wrote the hand mock test. This test got rid of the clutter of implementing interfaces in the test and having local variables. Also, there are no external libraries needed, like a dynamic mocking library. The test is simple and easy to read. The biggest drawback is dealing with the hand mock test file. It is untested code that I have seen a tendency for behavior to slip into, which is disastrous. It can cause a bug in your tests that take too long to track down. Ideally this doesnâ€™t happen, but I have seen it many times.

public class ScannerTest extends TestCase
{
   public void testScan()
   {
       MockControl control = MockControl.createControl(Display.class);
       Display mockDisplay = (Display) control.getMock();
       Item item = new Item("");
       mockDisplay.displayItem(item);
       control.replay();
       Scanner scanner = new Scanner(mockDisplay);
       scanner.scan(item);
       control.verify();
   }
}

Finally the dynamic mock test was written. This test was the simplest to write as a matter of process also the fewest lines of code. I never needed to leave the scope of the test function. It was just setting up my expectations and letting the test run. As Micah Martin pointed out to me, the test execution seems backwards and unreadable with dynamic mocks. The verification statements are at the beginning of the method and the execution is at the end. This is different than all the other tests in the system that follows an intuitive flow cycle of build, operate, and check.

With a little investigation I found Michael Feathers paper on Self Shunt (www.objectmentor.com/resources/articles/SelfShunPtrn.pdf).

Sentential Testing

Paul Pagel — Sun, 06 Aug 2006 04:51:00 +0000

In a project I have been working on, we recently decided to allow wrapped assertions to customize our unit tests. Our purpose was to make the unit tests be sentential enough to explain the meaning of the assertion in the execution of the assertion.

We can’t get rid of all developer comments (variable and method names) because, if we did, we would lose the ability to easily read and, consequently, easily maintain the code. In fact, writing easily readable code is a primary goal of good practices, since it is directly correlated with making code easily maintainable. This is important because maintenance is the most expensive part of the development process. However, we must be cautious about writting comments, since they can often have the opposite effectâ€š less maintainable codeâ€š when they are misrepresentations or plain lies. There is a balance that results in easily read and understood tests. Investing in writing tests to tell a story to the developers who may have to look at the tests in the future, makes maintenance and TDD easier and with a better flow.

We chose to achieve this balance by merging the assertions with the comments of the execution of the test, resulting in a pseudo-sentence. The statement is an explanation for the next developer to read. The form we chose is

Verify.That(positiveAssertionString).ProvedBy(subject).verb(predicate);

An example of one of these assertions is

public void test_PressingBrakesShouldDecelerateVehicle()
{

 int originalSpeed = vehicle.currentSpeed;
 vehicle.brake();

 Verify.That(â€š"Brakes decelerate vehicle.").ProvedBy(vehicle.currentSpeed).IsLessThan(originalSpeed);<br>

}

When a developer comes across this story, along with PressingEmergencyBrakeLocksTires(), SlamOnBrakesShouldSkid(), and BrakesShouldAntiLockAtIntervals(), the developer is told a story of what the class is doing. Why do we use custom asserts when good test names will solve the problem?

Changing tests should be cheap. As new designs and behavior evolve in the system, tests are changed to conform to the new structures. When implementing a new design to an existing system (such as breaking up an inheritance in favor of composition), I change the tests to fit the new structure on a macro level. However, this often implies that I am changing the behavior (if only slightly) to please the new design. Yet, test names, like comments, are not executable, so you canâ€š’t trust them to tell you what the tests test. On a system with heavy refactorings, a test might have its details changed five times without the developer thinking to verify the integrity of the names. An answer is to write sentential explanation of the test as the assert statement since the assert statement executes. I will trust execution over comments every time.

There is a project in its early stages called NSpec(.NET), which is a framework for assertions of a more sentential form. The project is based on the idea of Behavior Driven Development (BDD). RSpec, the same project for ruby has a form of BDD assertions which take full advantage of the features of the dynamic language. It allows you to add the assertion to the object from the test.

For example:
def pressingbrakesshoulddeceleratevehicle
vehicle.brake
vehicle.decelerating?.should_be_true
end

This is really cool! It defines the test as behavior of the object, which it is. However, when the code isnâ€šÃ„Ã´t ruby, there needs to be other means in place to bind the description of the assertion to something which executes.

Fri, 20 Jan 2006 05:37:12, nraynaud, Tests in a changing world You’re right, we are slowly going to agile world, and for now we have lots of meaningless test taken randomly from existing code (does it makes sense putting a multi megabytes source file in the compiler you test and expecting exactly 2008 errors? without even covering 10% of the compiler). We work on a language, yesterday, I added a restriction to the langugage, it took me 10 minutes to implement and test the change but the rest of the day to change all the others tests.

Moreover, I thank Intellij Idea that renames not only classes but also varialbes named after that class and even comments, this is on the way you takes.

Fri, 20 Jan 2006 13:13:22, David Chelimsky, should_be_decelerating I’ve just submitted a contribution to rspec that will make this even cooler. If vehicle can respond to any of these messages with a boolean value: vehicle.decelerating
vehicle.decelerating?
vehicle.is_decelerating
vehicle.is_decelerating?
then you can write this in your test:
def pressingbrakesshoulddeceleratevehicle
vehicle.brake
vehicle.should_be_decelerating
end
Admittedly, this may be confusing to a programmer who is looking for a “should_be_decelerating” method on vehicle, but the messaging is clear it fails (” should be true”) and it definitely improves the communication of intent. If you’re doing BDD (i.e. spec-first), you’ll get a !-NoMethodError-! on “decelerating”. Then it’s up to you to implement a method responding to any of the forms described above.

Fri, 20 Jan 2006 13:57:32, , How about using Higher Order Messaging style and let the user write:
vehicle.should_be.decelerating?
The test framework could mix should_be and similar higher-order messages into the Kernel module.

Fri, 20 Jan 2006 14:40:41, David Chelimsky, should_be That’s kind of how rspec works now. shouldequal, shouldcontain, shouldbe_true, etc are all mixed in to Object, so you can do things like someobject.someattribute.shouldbetrue. Your suggestion of tying it to a “shouldbe” method (rather than parsing the shouldbe_xxx message) might be more clear. I think, though, that “shouldbe.decelerating?” is weird to read (because of the question mark). Programatically, however, it does make the statement look more like the implementation. I’ll think on it some more…

PreFactoring

Paul Pagel — Sun, 23 Jul 2006 04:46:00 +0000

Prefactoring is when you see a piece of code which the story you are working on which has a refactorings which would make your story easier. I have seen prefactoring to be a dangerous process. On one hand, you save time when you know that this refactorings will need to be done. You are faced with the choice of writing temporary code (in the sense of duplicate then refactor) or refactoring, then writing quality code. The software designer in me always wants to choose the prefactoring solution, since it gets to make code cleaner, remove duplication, and be more efficient. Then I can stand on the mountain top waving my flag.

There are a few problems right off the bat. First, the uber-developer in all of us will refactor as much as we can, therefore refactor based scope creep is bound to show up. I don’t really know how to stay away from scope creep in this manner.

Prefactoring can lead to a version of design up front which is detrimental if you don’t need it. However, sometimes you know up front this design simplification will cut the story time in half. Do you prefactor? What kinds of smells make it ok or terrible to prefactor?

I have tried backing my way in and using test(s) as a life jacket, so once the test passes, the refactoring is done. However, the problem with this is it leaves me with half done refactorings. The code is constantly moving up in quality, however, it might not look it due to the inconsistencies produced by half done refactorings. I generally think of a complete refactorings as something that made my system better in some manner I would like developers who are extending the behavior of the system to use the refactorings as a model.

Do my refactorings make the system easier to extend? Half-factorings don’t, but they do provide a manageable slope moving positive. I don’t have the time to tackle the big refactorings, but I don’t want to leave them unfinished.

Wed, 22 Mar 2006 09:27:50, Uncle Bob, Half-factorings Paul, Keep the code clean! If the tests pass when the refactoring is half-done, then complete the refactoring. If you can’t complete the refactoring in this iteration, then keep putting effort into it during subsequent iterations. Make sure the team knows, so they can put some effort in too.

There are often times when a new story is easier to implement in a structure different from the one that exists. Refactoring (or “pre-factoring”) the system into that new structure to make that story easy to implement is often a good approach. However, leaving the refactoring in a half-finished state is messy.

Wed, 22 Mar 2006 18:30:36, Micah Martin, Prefactor ”’Prefactor”’ - I like that. If I counted all the time I’ve had to delete my prefactored code…. I believe there’s an Big Up Front Designer in all of us. Face it, BDUF is fun! Frequently I look at a prefactoring that I’ve just completed and realize I’ve been BDUFfing. Most of the time I delete it all because it’s too complex and unnecessary.

Sun, 23 Jul 2006 08:14:08, Sebastian Kubeck, BDUF To be honest, I never got BDUF right. Untill today, I need to start over one to four times untill I get what I want. I was convinced that I’m just lacking the skills to get it right the first time. Fortunately, I found out that people that are much smarter and much more experienced than me don’t get it right the first time either.

I learned in school that Mozart just wrote down his music which was already completely finished in his head. I was toled later that this is just another myth about this guy. Beethoven permanetly adapted his works. His handwritings are hard to read because his corrections. Bach adapted his works depending on the number of musiciants he could afford.

Conclusion: If not even the geniuses mentioned above get it right the first time, how should we “ordinary people” should ever be able to do it?