Some people have difficulty living up to the values and principles of the Agile Manifesto. Should we improve the Manifesto? Raise your game: we meant what we said.

Successful large enterprises (and less successful or smaller ones) often have practices and policies which make it difficult or impossible to follow Agile values and principles. For example, they may choose to outsource software development to low-cost inexperienced high-turnover developers on other continents or other planets. They may wish to compensate for this by providing software templates for these people to follow and learn from.

It’s a good idea …

Now on the one hand, if one is stuck with inexperienced developers on Mars, providing them with strict guidelines could be part of a valid approach, and providing those guidelines in the form of running tested software would surely be a good way to communicate.

And it’s not so very Agile …

On the other hand, there’s a good chance that this approach actually pushes against the notions behind Agility. The basic practice of extraterrestrial software development might seem counter to the Agile principles that “business people and developers must work together daily”. Providing direction in the form of software templates might seem counter to the notion that “most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.

It’s true, of course, that an organization could value those principles, and the others that this practice seems opposed to, and still find value in providing these templates. Certainly if I want to show people something about programming, I often show them examples. The template idea may not be any different.

But the question comes: should we update the Manifesto so as to open the door wider to ideas such as this one, and to the many other ideas that people have about how to do something like Agile within their “real world” organizations?

My answer is: No. We should not broaden the Manifesto in this kind of way. Here’s why:

The Manifesto is an Historical Document

Seventeen individuals who shared some common ideas got together for a few days, and wrote down the values and principles they shared. It was a moment in time, documenting what those seventeen people believed.  It doesn’t make sense to rewrite history.

The Manifesto is a Manifesto

We wrote a manifesto: a public declaration of our opinions, objectives, and motives. We did not write a constitution for an organization or a set of laws for a group to follow. A manifesto is not subject to updates in the way that a constitution or body of laws might be.

The Manifesto is Definitional

As Tim Ottinger put it on the XP list, the manifesto is definitional: it defines our meaning of the term “Agile” at that moment in time. We might revise it if we discovered that it didn’t express what we thought. If it does express what we thought, we cannot revise it.

The Manifesto is Already Too Broad

As I look back on the fifteen years I’ve been doing this, and the decade since the Manifesto, I see more and more people wanting to fly the Agile banner without living the Agile values and principles. On my most charitable day, I might feel that they are trying to become more Agile. On my least charitable day, it’s hard to see that, because the sum of their actions seems so blatantly counter to what we teach.

One cause of this, in my view, is that the values and principles are perforce a bit vague. In the values, we value both sides: the question is how much. In the principles, we value things like face to face communication: the question is how much.

Sources of Trouble in Applying Agile

Going too far?

In principle, it is probably possible to follow any Agile value or principle too far.

We might favor individuals and interactions over processes and tools so much that we wrote all of our code in binary. That would usually be inappropriate.

We might favor face to face conversation so much that we never wrote anything down. That would usually be inappropriate.

In principle, therefore, an organization might apply too much Agile. However, there are checks and balances in there, such as the requirement to “deliver working software frequently”, and “to satisfy the customer”, and to “reflect on how to become more productive”. A team that did those things is not likely to code in binary for very long.

Not going far enough

In practice, I have never seen or heard of a team that truly followed the Agile values and principles too far. I do know of teams who adopted a kind of faux-Agile and adhered to their flawed definition in the face of delivering no software, and making no customer happy. That’s not too much Agile, that’s too little.

On the other side of the balance, I have seen many teams who get very little advantage from Agile, because they are doing very little of it. These teams find ways to weasel within the principles. A common variant is “We value face to face conversations highly, we really do. But the reality is that our developers are on Mars.”

Well, guess what. If your developers are on Mars, and you can’t be with them, you’re not going to get the benefits of doing Agile — because you are bloody not doing Agile very well!

Therefore, No

Sorry. Changing the definition of Agile will not make Mars-based development work any better. The Agile values and principles are just fine. They state an ideal, and they state it pretty darn well when you consider the fools who wrote them.

Probably you’re not living up to the ideal. I often fall short of my ideals as well, in Agile, and in life. That doesn’t mean I should set lower ideals. It means I should raise my game.

Raise your game, successful large enterprise. We meant what we said.

At the Agile Developer Skills course at the Raikes School, I commented that we don’t usually test accessors. But we test everything. Is this a contradiction?

Last week, Chet, Cheezy and I presented a CSM class and an Agile Developer Skills class at the Raikes School at the University of Nebraska (Lincoln). Great fun. At the end, a concern was mentioned and I’ve decided to write about it.

As part of the class, we review participants’ code on the screen. Naturally, we have them trying to do TDD. A number of teams had written a bunch of accessors on their classes, and had dutifully written a test for each one. I commented that I don’t generally write tests for accessors. I tried to explain that the accessors are covered by other tests, but apparently I didn’t get that across, because there was a comment about the “contradiction” at the end. So I decided I’d try to explain a little more fully here.

To make what I do familiar to the class participants, I’ll do my example using the payroll stories we used in the class. To make it interesting to me, I’ll do it in Scala. I’m sure readers will have no trouble following along.

Let me call my shot. Here’s my plan: I’m going to implement a few of our payroll stories, all in one go, with a design that will require a number of accessors. I will write no accessor tests, and at the end of the exercise, all the accessors will be tested! No accessor tests, but the accessors tested? How is this possible? Read on …

My proposed design is to have a “Timesheet” object and an “Employee” object, and to use them in a “Payer” object. In the final system, I imagine a Payroll object looping over employees, and providing an employee and her timesheet to the Payer, but for now, that will be done under control of the test. The three main objects should be enough to show why I don’t test accessors directly.

My proposed test is a bit more of a reach than I would recommend to a TDD beginner … or even to myself. As a side project, let’s see if I get into trouble. I propose that Kate Oneal makes $150 an hour and that she works 40 hours regular time, ten hours time and a half, and 5 hours double time. (Kate would never really do that: she’s too smart.) Anyway, here’s our test:

import org.scalatest.Spec

class PayrollTests extends Spec {
  describe ( "Payroll Testing" ) {

    it ( "should calculate Kate base pay" ) {
      val employee = new Employee("Kate", 150)
      val timesheet = new Timesheet(40,10,5)
      val payer = new Payer(employee , timesheet )
      expect(9750)(payer.grossPay)
    }
  }
}

Not much to see here, really. We create an Employee, Kate, with a pay rate of 150. We build a time sheet with her hours. We create a payer on those two objects, and ask it for Kate’s gross pay. (I hope I calculated that correctly. Did you know that the Windows 7 calculator allows parentheses? It does.

This code does not compile, of course. So I’ll create the classes. This is quick, well within my ten minutes between running tests rule … I hope!

class Employee(private val _name: String, private val _payrate:Int) {

}

class Timesheet(
  private val _regularHours:Int,
  private val _ot1Hours:Int,
  private val _ot2Hours:Int) {

}

class Payer(private val _employeee:Employee, private val _timesheet:Timesheet) {

}

These three classes are almost enough to let the program compile. Just one more thing: we need a grossPay method:

class Payer(private val employeee:Employee, private val timesheet:Timesheet) {
  def grossPay = 666
}

This suffices to compile and run the test. We get, of course, “Expected 9750, but got 666″. We can continue to implement. We know, of course, that the grossPay result should be rate*regular hours + rate * 1.5 * ot1 hours + rate * 2 * ot2 hours. We type that in:

  def grossPay = _timesheet.regularHours*_employee.payrate +
                 _timesheet.ot1Hours*_employee.payrate*1.5 +
	         _timesheet.ot2Hours*_employee.payrate*2

This will not compile (no surprise) because we cannot access those values from the employee and timesheet objects. So one by one, we implement the accessors, until the compiler is quiet:

class Employee(private val _name: String, private val _payrate:Int) {
  def payrate = _payrate
}

class Timesheet(
  private val _regularHours:Int,
  private val _ot1Hours:Int,
  private val _ot2Hours:Int) {

  def regularHours = _regularHours
  def ot1Hours = _ot1Hours
  def ot2Hours = _ot2Hours
}

At this point we run the test again … and it is green!

That was a pretty big bite …

Three classes, a bunch of accessors, and one method, all from one test. That’s more than I’d normally do, and more than I’d suggest to people beginning with TDD. It all went well, but it might not have, and it would likely have taken ages to debug. In this case, I had very clearly in mind what I’d do … and I was lucky. Try this at home if you like … and be aware, when it goes wrong, that smaller steps are probably better.

However, we got to our desired end point:

Test everything … and don’t test accessors!

Note the result: all the accessors are tested … but we never wrote a test for an accessor. Instead, we had a test for the operation of the feature, which required that we write certain accessors: it could only execute correctly if the accessors were present and correct.  So the test for function drove us to implement the accessors (and a bit more operational code) in order to make the test run.

When you find yourself wanting to test-drive an accessor, and you have no other failing test, write a test that can only be made to work if you have that accessor. Make it a test that actually advances the application, not just a simple check of a value.

This is not just a trick of wordplay. Whenever we find ourselves thinking we need an accessor, we hold back until the code tells us that we need it, via a failing test. Then, and only then, we write the accessor … and our existing failing test tests the accessor along the way. Working this way keeps our eye on advancing the application, not just writing simple tests for code we may someday need.

Jon Bettinger has found a failing test! Excellent!

In a comment on an earlier article, Jon points out that the special check for a final bonus frame can trigger on the 9th frame, not just the 10th. The game can end 10-x-y with a strike in the 9th frame and an open frame in the 10th! A test that succeeds and one that fails are:

    it("should count not double count tenth frame bonus rolls" ) {
    	expect(11)(Game.score(List(0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 10,1,0)))
    }

    // fails !!!
    it("should count non-mark tenth frame after strike in ninth" ) {
    	expect(12)(Game.score(List(0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 10, 1,0)))
    }

My initial–but still thoughtful–reaction to this is that the current tail-recursive approach is doomed to fail without frame counting. I have a fairly simple counting fix in hand. And I suspect that a two-phase approach, parsing frames from the left and then summing, might be made to work without counting. Stylistic arguments aside, I think these count-free solutions are getting hard to understand.

I’d like to see one that shows up as clean and yet in full functional style.

I’ll show my current solution below. But first, some thoughts on helping.

The Code in My Head Always Works

It is fun, when someone is having trouble with a program, to suggest a “solution” that is significantly different from what they are doing, and it is tempting to declare it to work, and to be better. Recent experience here in the comments on these articles confirms the experience of my entire lifetime:

The code in my head always works. The code in the computer … not so much. What does this tell us about how to help some poor fool, like me, from a distance? Jon’s test is a perfect way to help, in that it’s just about the code and the fact that it doesn’t work. He didn’t even have to say “you tiny fool”.

But what about suggestions? It seems to me that a really good way would be to provide a little package built with tests, preferably TDD tests. A great way would be to provide an article, not like these Scala ones but like some earlier ones, showing the program, and understanding, growing bit by bit.

That’s really going to be time-consuming. It takes ages to write that kind of article. Great though.

If we want to help the other person rather than just dump an answer on them, we need to gauge just how quick they’re going to be.

I recall the first time I paired with Ward Cunningham. We were working on an interpreter program for a DSL my team was writing. He looked at what I had and–I believe–saw that it sucked. He said “You know how to write an interpreter in Smalltalk, right?” I hope I said something like “Well, I’m not sure, what do you mean?” Ward gave a hint; I didn’t get it; he gave a stronger hint; I still didn’t get it. This repeated about down to the point where he had to say “OK, now type a star …”.

At no time did he make me feel bad or say something to make himself feel superior. He just increased the level of help until I could get it … and not a bit more.

I should be that good, even once. :)

Applying this notion here, it seems to me that a “vague” kind of help would be a snippet of code that does something that might be useful if transformed into the current domain. Another kind might be a pointer to a technique. Finally, some working code.

When Philip gave me that snippet of code that I built on, I was in full learning mode, so I didn’t feel threatened by his solution. And I don’t feel threatened by people who are smarter than I am anyway, as I have been around them for so long. I might be a bit unique in that. So one needs to be cautious when tossing someone a solution. They might reject the solution; they might just install it; or they might examine it and learn.

This is easier in an environment of pairing and conversation, and difficult in a medium like this. Anyway, just something to think about.

The Current Solution

My current guess is is that a frame count is absolutely necessary to the solution, because it is seems impossible to look at the last few rolls and know whether they represent one frame or two. The reason is that the final frame is special.

So I decided to put a frame number back in, inside my function. First I changed the tests to insert 1 (integer representing first frame) as a parameter in the score method, then made it work, then added a score(rolls) polymorphic entry point. Could have been done another way. Anyway, here’s what I have, and it works. Well … it passes all the tests.

object Game {
   def score(frame: Int, rolls: List[Int]):Int = {
      rolls match {
           case List(first, second) => first+second

           case List(first, second, third) if frame == 10 => first+second+third

           case 10::second::third::theRest
              => 10+second+third + score(frame+1, second::third::theRest)

           case first::second::third::theRest if (first + second == 10)
                => 10+third + score(frame+1, third::theRest)

           case first::second::theRest
                 => first+second + score(frame+1, theRest)
      }
   }

   def score(rolls: List[Int]):Int = score(1, rolls)
}

I’ve highlighted the changes. Let me know what you think, and how to do better. Thanks!

Philip Schwarz provided a nice-looking implementation. Let’s look at it and try to build on his ideas.

Philip offered this version in a comment on an earlier article:

def score(rolls : List[Int]) : Int = rolls match
  {
  case List(x,y) => x + y
  case List(10,x,y) => 10 + x + y
  case List(x,y,z) => 10 + z
  case (10::x::y::rest) => 10 + x + y + score(x::y::rest)
  case (x::y::z::rest) => if((x + y) == 10)
    10 + z + score(z::rest)
    else x + y + score(z::rest)
  }

Let’s see what he did. First of all, instead of that silly idea of including the total on the front of the list, he just wrote the recursion to return the total directly. That was boneheaded on my part. I can only plead youthful inexperience and ask for mercy based on my long years of service.

First, I’ll fix that in my version:

class Game(rolls: List[Int]) {
   def score = scoreReduce(rolls)

   def scoreReduce(rolls: List[Int]):Int = {
      rolls match {
           case Nil => 0

           case 10::second::third::Nil
               => 10+second+third

           case first::second::third::Nil if (first+second==10)
                => first+second+third

           case 10::second::third::theRest
              => 10+second+third + scoreReduce(second::third::theRest)

           case first::second::third::theRest if (first + second == 10)
                => 10+third + scoreReduce(third::theRest)

           case first::second::theRest
                 => first+second + scoreReduce(theRest)
      }
   }
}

That works nicely. We notice that Philip coded things like x :: y :: Nil as List(x,y). That’s more clear. Let’s do that:

class Game(rolls: List[Int]) {
   def score = scoreReduce(rolls)

   def scoreReduce(rolls: List[Int]):Int = {
      rolls match {
           case Nil => 0

           case List(10, second, third)
               => 10+second+third

           case List(first, second, third) if (first+second==10)
                => first+second+third

           case 10::second::third::theRest
              => 10+second+third + scoreReduce(second::third::theRest)

           case first::second::third::theRest if (first + second == 10)
                => 10+third + scoreReduce(third::theRest)

           case first::second::theRest
                 => first+second + scoreReduce(theRest)
      }
   }
}

This works. Now notice that Philip doesn’t have quite the same cases that I have. I’m unwinding all the way down to an empty list. I’m handling the case of the last frame having three elements, but not the case of it having only two. Philip added in the case of two elements, which terminates the recursion, so he doesn’t have to deal with Nil. We can showthat as part of the next display (I’ve done it separately but will save you reading just that one bit.)

First, look at both his version and mine. I’ve highlighted the bit of interest in my version above. Philip gave us the trick of representing the end cases explicitly. The game always ends either with a frame of two, or a frame of three which is either a strike (10 :: first :: second) or a spare. We note, however, that the answer returned in either case is the sum of the three balls in the frame. Let’s do that, then look at the code again:

class Game(rolls: List[Int]) {
   def score = scoreReduce(rolls)

   def scoreReduce(rolls: List[Int]):Int = {
      rolls match {
           case List(first, second) => first+second

           case List(first, second, third) => first+second+third

           case 10::second::third::theRest
              => 10+second+third + scoreReduce(second::third::theRest)

           case first::second::third::theRest if (first + second == 10)
                => 10+third + scoreReduce(third::theRest)

           case first::second::theRest
                 => first+second + scoreReduce(theRest)
      }
   }
}

Now Philip handled things differently at the bottom of the match statement. I broke out strike, spare, and open frame into three cases. He broke out strike, then folded the last two of my cases into one, with an else. I think I’ll leave it my way.

Now there’s one more thing to do. Since the function scoreReduce doesn’t use my dim format with the total on the front, it no longer needs to be an auxiliary function, so we can let it be the score function directly. That’s a bit tricky, though, because I built Game as a class, with rolls inside it. The way things are set up now, we almost might as well move the whole function score into our test class. I’ll not go that far: I want a solution that stands alone from the tests.

Instead, I’ll change Game to an object with just one method, score. That makes things turn out like this. First the tests:

import org.scalatest.Spec

class ExampleSpec extends Spec {

  describe("A Bowling Game") {

    it("should score all gutters as zero") {
    	expect(0)(Game.score(List(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)))
    }

    it("should score all 5,4 as 90") {
    	expect(90) (Game.score(List(5,4,5,4,5,4,5,4,5,4,5,4,5,4,5,4,5,4,5,4)))
    }

    it("should score spare game 6, 4, 5, 2 as 22") {
    	expect(22)(Game.score(List(6,4,5,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)))
    }

    it("should score strike game 10, 5, 2, 7 as 31") {
    	expect(31)(Game.score(List(10,5,2,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)))
    }

    it("should score perfect game as 300" ) {
    	expect(300)(Game.score(List(10,10,10,10,10,10,10,10,10,10,10,10)))
    }
  }
}

Then the Game object:

object Game {
   def score(rolls: List[Int]):Int = {
      rolls match {
           case List(first, second) => first+second

           case List(first, second, third) => first+second+third

           case 10::second::third::theRest
              => 10+second+third + score(second::third::theRest)

           case first::second::third::theRest if (first + second == 10)
                => 10+third + score(third::theRest)

           case first::second::theRest
                 => first+second + score(theRest)
      }
   }
}

OK. That's probably more like it. I expect that this is in the range of tolerance for a functional solution, with people perhaps objecting to notation and having better ideas. I'll be very interested to see if something substantially different comes up.

Go for it!

My critiXXXXX advisors expected a more function-oriented solution. Here’s something a bit better, perhaps …

I was at a loss as to how to deal with a function that scores one part of an input list and consumes a different part. Finally I got the notion of a function of two parameters, a total and a list, which adds to the total based on the scoring part and calls itself recursively with the appropriate list remainder.

The result is that I have dropped the Framer class, and added the recursive function to the Game class, which now looks like this:

class Game(rolls: List[Int]) {
   def score = scoreReduce(0,rolls)

   def scoreReduce(total: Int, rolls: List[Int]):Int = {
      rolls match {
           case Nil => total

           case 10::second::third::Nil
               => total+10+second+third

           case first::second::third::Nil if (first+second==10)
                => total+first+second+third

           case 10::second::third::theRest
              => scoreReduce(total+10+second+third, second::third::theRest)

           case first::second::third::theRest if (first + second == 10)
                => scoreReduce(total+first+second+third, third::theRest)

           case first::second::theRest
                 => scoreReduce(total+first+second, theRest)
      }
   }
}

I started with the four black cases. Those pass all my tests but for the perfect game, which was scored 320 rather than 300. What happened was that on the last strike, we score up the 300, but then we return the rest of the rolls (the bonus rolls) for one last go, as if they were a frame. In bowling, the bonus rolls only provide a bonus for a mark in the final frame: they do not constitute a frame of their own.

The two red cases differ from the black ones in that they are explicitly talking about the end of the list: first::second::third::Nil and so on. Instead of recurring one more time, they just return the final value.

So … I feel this is more in the direction of a functional solution. I can imagine going further, and perhaps I will. We have the fact of a two-part argument, the total and the rolls. We might be able to put the total in front, or on the back, and update it there. Front will be easier, as Scala prefers us to work at the head. Let’s see …

class Game(rolls: List[Int]) {
   def score = scoreReduce(0::rolls)

   def scoreReduce(rolls: List[Int]):Int = {
      rolls match {
           case total::Nil => total

           case total::10::second::third::Nil
               => total+10+second+third

           case total::first::second::third::Nil if (first+second==10)
                => total+first+second+third

           case total::10::second::third::theRest
              => scoreReduce(total+10+second+third::second::third::theRest)

           case total::first::second::third::theRest if (first + second == 10)
                => scoreReduce(total+first+second+third::third::theRest)

           case total::first::second::theRest
                 => scoreReduce(total+first+second::theRest)
      }
   }
}

I think that is in some sense better. All the work is being done in the patterns, which is perhaps appropriate. The patterns are a bit opaque because of the necessity to embed the two or three rolls of interest into the middle of the list (total, rolls of interest, …). It might be possible to improve that aspect with some typographic tricks.

Anyway, I think it is more functional than it was and I look forward to comments. It has been a long time since I worked in a functional style. (No smart remarks now … :) )

I’ve been working with Scala a bit, just to learn what it is. I’ve found it interesting, if frustrating. Here is a bowling experiment.

The bowling problem that Chet and I use for TDD demonstrations is somewhat different from the one that Bob Martin uses. Ours can be stated: “Given a list of rolls of a legal game of bowling, compute the final score of the game.” This turns out to be just big enough to be interesting and to be something we can do in about an hour, with plenty of discussion and questions.

I wrote this one in full TDD style, but I will present here only the final version, with some discussion. Mostly I spent the early part of the project trying to learn the Scala language and tools, and trying to work in what I hope is a Scala-like style. I’ll leave the article open for comments in case you’d like to advise me otherwise.

First, the Tests

Here are the tests, written in ScalaTest Spec format. I kind of like that form, as it means I don’t have to make up really weird test method names.

import org.scalatest.Spec

class ExampleSpec extends Spec {

  describe("A Bowling Game") {

    it("should score all gutters as zero") {
    	val game = new Game(List(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0))
    	expect(0)(game.score)
    }

    it("should score all 5,4 as 90") {
    	val game = new Game(List(5,4,5,4,5,4,5,4,5,4,5,4,5,4,5,4,5,4,5,4))
    	expect(90) (game.score)
    }

    it("should score spare game 6, 4, 5, 2 as 22") {
    	val game = new Game(List(6,4,5,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0))
    	expect(22)(game.score)
    }

    it("should score strike game 10, 5, 2, 7 as 31") {
    	val game = new Game(List(10,5,2,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0))
    	expect(31)(game.score)
    }

    it("should score perfect game as 300" ) {
    	val game = new Game(List(10,10,10,10,10,10,10,10,10,10,10,10))
    	expect(300)(game.score)
    }
  }
}

As always, these are shown in the order created.  Nothing special here, I just create a game and expect its score. I did, of course, work one test at a time, making each one work before creating a new one.

I had a design in mind, as always. I think it is neither desirable, nor quite likely even possible, to work with no design in mind. The trick is to make no steps in the direction of the design until the code calls for them. You’ll have to take my word for it that I accomplished that. The point here is just to show you the result, which I think is interesting.

The design I had in mind is one that Chet and I tried in Java or C# last week. Under the Game object, there is a “Framer” object that steps along the sequence of rolls, positioning itself to the start of each frame, and adding the score of that frame to the game total. In Java, we wound up having that object maintain an index into the array of rolls, and it would step that index by 2 for spares and open frames, and by one for strikes. (All done one step at a time, of course.)

Now, the Game

The game didn’t change after I first refactored in a rudimentary framer. It goes like this:

class Game(rolls: List[Int]) {
   def score = {
      val framer = new Framer(rolls)
      var total = 0
      for (frame < - 1 to 10) { total += framer.score }
      total
   }
}

Not much to see here. As I look at it now, I suspect there is a more Scala-like way  to do this. If you see one, please let me know.

And, the Framer

The Framer class has gone through a number of iterations, from a procedural, indexed approach, to this more functional one. One essential idea is that this Framer, rather than indexing through the list of rolls, actually consumes it. The other idea is that at each frame position, the Framer adds together two rolls, or three rolls, to get the frame score. An open frame scores just the two rolls of the frame, while a strike scores the one roll of the frame and the next two rolls, while a spare scores the two rolls of the frame and the next one. Since 2 + 1 equals 1 + 2, both “mark” frames wind up scoring three rolls.

I first had the idea of creating a tuple saying how many rolls to score, and how many to consume or “eat”. Then I hit on using Scala pattern matching to identify which kind of frame we’re dealing with.

Here again, I’m open to comments on style, and offers of better ways of doing it.

class Framer(var rolls: List[Int]) {
   def score = scoreFrame(frameList)

   def scoreFrame(sumAndEat: Tuple2[Int,Int]) = {
      val rollsToSum = rolls.take(sumAndEat._1)
      rolls = rolls.drop(sumAndEat._2)
      rollsToSum reduceLeft (_+_)
   }   

   def frameList = {
      rolls match {
         case List(10, _*) => (3,1)
         case List(a:Int, b:Int, _*) if (a + b == 10) => (3, 2)
         case _ => (2,2)
      }
   }
}

Overall, it was a somewhat frustrating experience, but mostly this was due to trying to hook together all the tools one would need. Partly, however, I found the two books I had, Wampler’s and Venkat’s, didn’t lend themselves to my style of learning, whatever that is.

Some of that is due to the fact that I am a Windows user and prefer to use an IDE. I realize this calls my masculinity into question, but I can live with that.

Anyway, that’s my report. I look forward to your comments, and I’ll probably write a few more articles about my experience with Scala. Enjoy!

Updates from Ilmari

Based on Ilmari’s suggestions, we can rewrite Framer as:

class Framer(var rolls: List[Int]) {
   def score = scoreFrame(frameList)

   def scoreFrame(sumAndEat: (Int,Int)) = {
      val rollsToSum = rolls.take(sumAndEat._1)
      rolls = rolls.drop(sumAndEat._2)
      rollsToSum reduceLeft (_+_)
   }   

   def frameList = {
      rolls match {
         case 10 :: theRest => (3,1)
         case first :: second :: theRest if (first + second == 10) => (3, 2)
         case _ => (2,2)
      }
   }
}

Frankly, I’m surprised by the match … apparently everything inside a case is taken implicitly as abstract parameters. Very interesting.

I couldn’t find a way to get rid of the ._1 and ._2 in the scoreFrame method: everything I tried to give those two Ints names wouldn’t compile.

As for Ilmari’s comment about the 1 to 10, I don’t see how to get rid of that either. Would like to learn more …

Another Pattern Match

I fiddled with the pattern match a bit, making it return two lists, the rolls to sum, and the rolls to work with next time. You’ll notice I’m still referring to the rolls state variable and storing over it. The scoreFrame method is simpler now: I’m not so happy with the pattern itself. Your thoughts?

class Framer(var rolls: List[Int]) {
   def score = scoreFrame(frameList)

   def scoreFrame(sumAndEat: (List[Int], List[Int])) = {
      rolls = sumAndEat._2
      sumAndEat._1.reduceLeft (_+_)
   }   

   def frameList = {
      rolls match {
         case 10 :: second :: third :: theRest =>
         	(10 :: second :: third :: Nil, second::third::theRest)

         case first :: second :: third :: theRest if (first + second == 10) =>
         	(first::second::third::Nil, third::theRest)

         case first::second::theRest => (first::second::Nil, theRest)

         case Nil => (Nil, Nil)
      }
   }
}

Just for something to do, I’m learning? Scala. Having deep confusion making JUnit suites run. Advise me in comments if you’re up for it?

Reading Venkat’s book, and Dean Wampler’s book, I decided that rather than run things at the command prompt … how very last century, I’d write a bunch of JUnit tests to test and document the things I was trying. It seems to me to be a much better way to do things.

(Why am I not using ScalaTest or another such system? Largely because I know JUnit and felt no desire to try to learn two things at once. And yes, I know I should get a Mac.)

It’s going pretty well so far, or was until I tried to set up a suite of tests. I’ve got a big JUnit test file, and it was just getting irritating to add another test to it, so I started another one, thinking maybe someday they’d even get organized. But of course I’d like to run all the tests frequently just because I like the jolt of the green bar.

So I looked up how to do a Suite. There’s nothing really solid on the Web but I found a couple of consistent items. They are almost working but some of it has me confused. I’ll note down here what I’ve got and maybe if you grok Scala you can advise me in the comments.

I have my main test file. It looks like this:

import org.junit._
import org.junit.runner._
import org.junit.runners._
import Assert._
import StringUtil._

class TestSomething { 

	@Test def hookup() {
		assertEquals(2,2)
	}

	@Test def someArrayStuff {
		val array: Array[String] = new Array(5)
		array(0) = "abc"
		assertEquals("abc", array(0))
		assertEquals(null, array(1))
	}
        ...
}

There are a couple of class files, not relevant here. There’s another test file that I just started:

import org.junit._
import org.junit.runner._
import org.junit.runners._
import Assert._ 

class TestMore {
	@Test def hookup4 {
		assertEquals(4,4)
	}
}

As soon as I started with that, I realized I wanted a suite, to run everything. I have that in place, like this:

import org.junit._
import org.junit.runner._
import org.junit.runners._
import Assert._ 

@RunWith(classOf[Suite])
@Suite.SuiteClasses(Array(classOf[TestDummy]))
class TestEverything

class TestDummy {
	@Test def hookup {

	}
}

This is lifted from a couple of examples I found on the Web. I’ve fiddled a bit with what is in the RunWith class, and what is in the SuiteClasses array. None of them seems to work unless I have at least a dummy test in the same file, and I seem to require the empty class (TestEverything) as well.

As this stands, all the tests run and show green or red as they should. JUnit’s Eclipse GUI looks like this:

Notice that TestDummy shows up twice, once in the top-level listing where the other tests are. But at that level TestDummy does not have green check marks. It shows up again, under TestEverything, and there it will have checks as appropriate. I’ve fiddled with not having any tests in the TestEverything file, and that seems to fail entirely. I’ve tried various names, or putting the names of the other test classes in the @Suite entry. In every case, I either get errors or an odd display where some of the classes show up twice, on their own or under TestEverything.

Advise me, please … have you a configuration of JUnit with Scala with Suites? I’d love to see how it works.

And OK, let me know what testing tool you’re using with Scala as well. But I’m not going to get a Mac.

Thanks!

“His brand is bad: my brand is good.” Isn’t it well past time we got over that kind of thinking? I’ll take a good idea from anywhere. So should you.

You’re interested in having projects that are more successful. At least you should be. You may well find great value in Scrum, or XP, or Lean, or Kanban, or DSDM, or whatever. I hope you do. Keep your eye on the ball, however. The point for you shouldn’t be to do Scrum or XP or whatever: it should be to do as many things as you can to be more successful, and as few as you can that get in the way. Those ideas can come from anywhere, and the  better you and your team want to be, the wider the range of ideas you need to consider.

When you look for help or training, however, you find yourself dealing with companies and individuals. These people often have a preferred style of “Agile”, a preferred set of approaches and practices. Everyone is like that: it’s perfectly natural. However, these companies and individuals also have selling to do. They want you to buy their training, their coaching, their ideas. This, too, is natural.

Unfortunately for you, the selling can get in the way of your learning. Too often, the advertising and comments from these people try to tear down the  other guy, to make their own offering look better. This is tragic, because there are good ideas everywhere. If their tearing down the other guy turns you off, as it does me, you may miss the good ideas that are lurking under the venom. If you buy into their story about the other guy, you may miss the good ideas that he has to offer.

Either way, you lose. Either way, the industry loses, because good ideas are what we need.

Your practice needs to be one of continual improvement. You’ll find yourself in places where some ideas will help, others will hurt, and very many seem to make no difference. If you choose your ideas from a larger pool of notions, you’re more likely to find one that helps.

Continual Improvement

One essential aspect of Agile is to reflect on what has gone before, and to adjust what we do to make things better. This is central to all those ideas about maintaining a constant rate of progress, to working together effectively, to delivering software in small increments, and so on.

In Scrum terms, the team must “inspect and adapt”.

[The point of this article is synthesis, adopting good ideas from wherever we find them. This particular idea  happens to be very  nicely expressed in Scrum. This is not a game of Scrum over Your Favorite Method: it's a game of Find an Acorn, Take It Home.]

What does “inspect and adapt” mean? It means we pay frequent attention to what is going on, and we look for ways to improve how we’re doing. We change our process. We change what we do. We adapt.

To adapt, we must choose what to try. Not all choices are equally good. Sometimes it’s not easy to tell. Often we have to try something, assess how it goes, then adapt again. Let’s look at an example.

Tasks Piling Up

Perhaps in our team we notice that there are always a bunch of important tasks that are not getting done. This isn’t good and we must fix it. What’s going on?

We’re not all the same: you are good at one kind of thing, and I’m good at another. It is natural for us to focus on our kind of work. Maybe you do the GUI work, and I do the database work. Dave over there does the testing.

In our planning meetings, we divide the stories or features up into what are we call “technical tasks”. You grab the GUI ones, I grab the database ones, Dave grabs the testing ones … when you and I are finally ready for him to test something. When all the programming tasks for a story are done, we integrate, Dave starts his testing tasks, finds problems, we fix them, and voila! story done!

Often, by which I mean almost always, it doesn’t quite work out that way. We get to the end of the iteration or Sprint or deadline, and we have lots of tasks done, but not many stories. Often I’ll see teams with 90 percent of their tasks done, but only twenty-five percent of the stories done, or even fewer. And it’s not just testing, either. We may find that we have lots of tasks done but many stories aren’t even ready to be tested!

We aren’t doing well, so we inspect: we have a retrospective. The cause of our problem may not be obvious.  Some possible causes include:

• Maybe some technical tasks are necessary, but no one likes to do them. So people do other valuable things, but none of the stories get done because no one works on the nasty bits.

• Maybe we have lots of GUI changes, not much database. I get all “my work” done, but you can’t get all “your work” done. This could happen on a week-to-week basis, or it could be generally true.
• Maybe we do things in different orders. You worked on A, B, then C. You completed A and B, and didn’t quite get your C work done. Meanwhile, I worked on C, then B, then A, and didn’t quite get my A work done. Two-thirds of the tasks are done, but only one story ever gets to Dave to be tested.
• Maybe you and I code like demons. We get “our part” of A and B and C done, and dump them on Dave. Dave does a little testing on each, but at the end of the Sprint, none of them are working well enough.

These causes may call for different solutions. We might need another GUI person. We might need to “swarm” on stories, all working on first one, then the next. We might need to put more focus on the nasty tasks, maybe even doing them first. We might need more testers. Depending on how well we have identified the problem, and how creative we are about solutions, we may do better, about the same, or worse.

We are trying things without knowing quite what will happen. This is natural: our world looks like this:

We start in that middle drab yellow area. We have imperfect knowledge of what’s around us, just guesses. Red is bad. Green is good. Yellow is about the same.

Heading off to the east, things get harder and harder. But if we stick with it a while, we come upon a lovely green area of improvement! If we head north instead, we have to slog but at least things don’t get worse. West is interesting: it looks good, but if continue for long we get in trouble.

How could that happen? Well, let’s consider Dave and the testing.  We programmers code stuff up, get it to compile, check it a little, integrate it, and hand it to Dave, our tester. Dave tests away, files bugs, and we fix them. Meanwhile we code other things. We notice that Dave  is overloaded, because many stories are “done but not tested”. Going west means “hire another tester”.

Too often, “hire another tester” patches over the issue but is not sustainable. In incremental development, we need to retest the software that has already been written, to be sure we didn’t break it in building newer features. So the testing load increases, increases, increases. So our “hire another tester” strategy results in needing more and more testers. This is simply not sustainable: as Chet Hendrickson puts it, sooner or later we run out of parking spaces for testers.

We need scouts. We need a better map.

Because we don’t have a map of the territory, we don’t know where we are, and we surely don’t know where to go.  Other people have been here, though, and found ways to assess the path, and good paths to take. We need their help.

It might also be that we didn’t even recognize the right problem: it often happens that we are blind to things going on around us. A raw approach of “inspect and adapt” can miss the problem, or miss the solution, especially if we have to make everything up.

We need to borrow all the tools we can to assess the situation, and to get the best ideas possible to do when we hit our kind of terrain. In other words, we need good diagnosis skills to see what’s wrong, and we need good decision skills when we decide what to do. How well we do at those things depend on the quality of our tools and ideas. We need to be open to tools and ideas from anywhere!

Let’s look at alternative ideas about finding and diagnosing our task problem, and how to fix it:

Diagnosing the Problem

A “pure Scrum” approach might have the team drawing a “burn down” chart, showing tasks done versus time. Here’s a free example from Wikipedia:

This chart may well show regular progress toward completion, at some smooth rate. What it doesn’t show is that more and more of the tasks not done are testing tasks. Until a retrospective, the team might not even be aware of what’s happening! Even then, many of the team members may be saying “I got my part done”. This may be true, but to someone who wants features, not tasks, it’s not very helpful.

(In the Kate Oneal story, Slices, Kate says: “Features are what we’re trying to buy and features are how we measure our progress. If I came into your feature store today, planning to buy five features, there just wouldn’t be any on the shelf to buy. I’d have to go home without features, and your feature store would have to run for another week with no revenue …”. Kate has it right: part done is Not Done.)

The “official” Scrum answer isn’t helping us find this problem as well as it might, much less fix it. It turns out there is a good idea waiting to be borrowed from Kanban: the task board. Here’s one from Mike Cohn. Click the link for Mike’s full article.

To maintain a task board, the team puts all the tasks on cards, and creates a board showing all the important states that a task might be in. To Do is one. Done is another. Usually, on a task board, we don’t break out things like GUI or Database: instead, we’ll just have In Process. Aboard like this can help, a bit. We might notice that early in the Sprint, none of the testing tasks are In Process. We ask why, and the answer is “There isn’t anything to test yet. ” This seems plausible enough. Later on, all the testing is In Process, and all the GUI and Database tasks are moved to “Done”, or to “Waiting for Test” if we were clever enough to have that state.

Watching the task board, we have a chance to see what’s going on sooner. We might otherwise need to wait for a retrospective to have a chance to notice that we are blocking on testing.

A team that limits itself to one name brand, Scrum in this case, may not discover a task board, because they know that task boards are not part of “our method”. Nonetheless, the task board, which a team might hear about as part of some other discipline, perhaps Kanban, would be very helpful to them.

What we have noticed is that there is an idea, that we heard about from the Kanban side of things, that is useful. We don’t need to repudiate everything we know about whatever we were doing before–Scrum in this case–in order to pick up a good idea from Kanban. We don’t have to buy into a whole alternate worldview and start wearing Kanban t-shirts. We have work to do here. We’ll just build the darn task board.

And, if we’re wise, we’ll look more deeply into the knowledge space around ideas we find. The task board doesn’t stand alone–it may not even be sourced in Kanban. It’s used there because it works will with Kanban’s other ideas. What are they? How can they help us.

Same thing if we find a useful idea from Lean or any other realm of thought. Let’s appropriate it into our world … and let’s look more deeply at that world. Ideas are not fenced in. Ideas relate to each other. Let’s observe what we can, use what we can, and think about it all.

Synthesis:  ”Yes, And”. Not “Either/Or”.

For our projects to be successful, we need to draw from the whole world of ideas, not just from one little part of it. So when someone starts ranting about Scrum or Kanban or Lean or XP being “the way”, let’s not drop everything and adopt a new way of walkin’ and a new way of talkin’. Just look over there, find good ideas, and bring them into our own world.

Listen to all the gurus and vendors. Are they pushing Scrum, Lean, Kanban, or XP, or something else you don’t know all about? Great! Listen! There are good ideas there. But as they try to help you, are they also trying to tear down some other process? Don’t listen to that, that’s just their fear talking. Your success is about what you do, and you won’t get extra credit for sticking with just one brand. You’ll get extra credit for building the best process you can.

In the end, it’s about your world anyway. You’re here to be effective, not here to be Pure Scrum or Pure Lean or Pure Kanban. Effective. That’s the point.

Should we ease into Agile, or jump in? How fond of being eaten by bears are you?

We should be trying to be successful. We agree, I hope, that our chances of success depend in large part on what we do. Our chances depend on our practices. How quickly–or how slowly–should we adopt practices?

If we look at the map of the continent of all practices, Agile is a region somewhere in the middle, where all those useful practices cluster. We all agree roughly where this region is and have our favorite areas inside it, called XP and Scrum and so on.

Most of us probably agree that the closer a team is to the core of the Agile region, the better things seem to go. Their chances are better as they do more and more of the practices, and do them better.

Today, many teams are out in the wilderness, endangered by bears or worse. I’d like to see them get to safety as quickly as possible. The best way that I know to get to safety is to do as many of the practices as we can, as well as we can, as soon as we can. The more urgent it is to get to safety, the more important it is to add practices briskly rather than ease in to things slowly. If we move too slowly, those bears may get us before we get to safety.

We all know that there have been successful projects that didn’t seem very “Agile”. And there certainly have been projects that we might have called “Agile” but that were not very successful. Now, my experience suggests to me that agility and effectiveness are correlated: use of Agile techniques tends to improve effectiveness. Maybe the “spectrum” of Agility and Effectiveness looks something like this, with good things tending toward the upper right, and not so good toward the lower left.

Considering just the “Agility” axis, let’s look at the placement of some practices, focusing on the Agile Manifesto notion of “Individuals and Interactions over Processes and Tools”.

Similarly, we can look at design. If a team builds a great design and understands it well, that’s better than if they have a design that they understand only fairly well. We believe that if they create the design they will probably understand it. Even then, that design may not be understood across all teams, and of course, not all teams produce “great” designs.

In any case, a well-understood good design could be better than a great design understood by only a few.

So on our Agility/Effectiveness chart, we can think about an “Agile Direction”, where moving right is better, and an “Effectiveness Direction”, where moving up is better. Agilists believe that moving more toward Agility is likely to move you more toward Effectiveness.

Are there exceptions? Perhaps! It depends where you start, and what you change.

Sure, a highly skilled team can produce a design that is hard to beat, shown at top right in the picture below. But a team with low skills cannot produce a good design, no matter how self-organized they are, as shown by the blob in the lower left.

So what if we gave that low-skill team a good design to work with, made it easy to apply, and helped them understand it? The team might well be more effective, moving upward, while being less “Agile”, and moving toward the left!

I find this notion at least credible, and certainly we can imagine a situation where we do not have the time or ability to upgrade the team by hiring or training, and we must do something. And maybe the team do learn something from being given this design.

Every Agile team uses some provided tools, and reuses design ideas, most of which are “owned” by the team members. This is only a bit different, in that the team members probably didn’t own this design until someone gave it to them.

So what conclusion should we draw? One possibility is that there are projects, or teams, or situations, where Agile will not work. I wouldn’t go that far: what we have here is a case where we chose not to follow the Agile path.

From the Agile viewpoint, what we have here is a fundamental violation of the Scrum principle that the software must be done by a cross-functional team: a team that has all the skills needed to do the project. This team doesn’t have the design skills to do the project … and therefore they are not an Agile team at all!

That doesn’t mean they are evil, or that they can’t succeed. If you don’t have an Agile team, and can’t get one, well, try things that make sense. Investing in the Agile direction is likely to pay off more, but it may be difficult to impossible to invest, and it could take time. In the meantime, do what you will … and please don’t call it “Agile”. It just isn’t.