Raible Designs

Lean Teams: Doing more with less

This evening I attended the Denver Rails User Group (a.k.a. DeRailed) to hear a presentation by Marty Haught. It was titled "Lean Teams: Doing more with less" and the following are my notes from the event.

Today's talk is about "Rocking with Ramen" - a.k.a. working with less funds to make great things. Lean comes from the manufacturing world in that you should Add Nothing but Value. The most important thing you should do is add business value.

The Seven Wasteful Sins for manufacturing are:

• Overproduction
• Inventory
• Extra Processing Steps
• Motion
• Defects
• Waiting
• Transportation

The key to fighting overproduction in software is to trim features to those that achieve the greatest value. You should do "the simplest thing that could possibly work" and delay commitment as long as you can because YAGNI.

A minimum viable product is a starting place for validated learning with the least amount of effort. It should be embarrassing. Early adopters see the potential. Rails Rumble and Startup Weekend are good examples of promoting this type of development.

Unused and useless features are best solved by feedback-driven development. This is a process for validating value and creating software that people use. The end result is that you create software that people use and you're able to pivot your plan as you learn. The benefit of this is you stay humble and you don't drink the Kool-Aid (e.g. VC's tell you you're going to be the next Twitter).

The first part of feedback is "Pirate Metrics" by Dave McClure. The main things to track are acquisition, activation, retention, referral and revenue (AARRRR!). The main things you should gather from metrics is they're actionable and should help you make decisions. Vanity metrics like hits-per-month and such should be ignored.

Other feedback options include net promoter score (popup question to ask if users would recommend to a friend), feedback form (make it easy for users to tell you what you think about your product), A/B testing, and usability testing.

The final point is that it's OK to remove features.

To reduce extra processing and waiting, you should implement "Kanban". It's a pull-based system for a continuous flow of work and can be used in software projects to manage/schedule work for cross functional teams. It's an expression of just-in-time and has an emphasis on flow. It's all about getting across the board as fast as possible. In agile development, this is often expressed as a card-based system on a wall in the same room as your development team. Things can only move from the left-to-right as there is space for them. Marty is showing a screenshot of a "Zen" tool he uses on his projects. It has 3 columns (Definition, Work and Verification) from left-to-right that allows you to easily move stuff.

The most important thing about Kanban is it helps to eliminate constraints. The Zen tool only allows a certain amount of items in the "Work" column and it visually communicates blocked items by moving them to the top and highlighting them with a red border. The Zen tool that Marty is showing looks similar to Rally, but is much more visually appealing.

The benefits of Kanban include:

• simple, less process
• less inventory of requirements/stories
• limit work in progress, maximize throughput
• less time in meetings
• more naturally represents story lifecycle
• more easily spot bottlenecks
• estimate only if it adds value

Kanban promotes tracking how long it takes for a story get across the board and into production vs. tracking velocity of a team.

On my current project, we use Rally, a small team and have two week iterations. Because the things that Marty is talking about seem to be things we're already doing, I asked him how Kanban differs from Scrum with small teams. He explained that this biggest difference is Kanban is most useful when you're pushing things to production with each iteration.

The most controversial practice that Marty promotes is Continuous Deployment. This is the automated deployment of code to production. It includes automated testing and continuous integration, simple deployment/rollback scripts, a successful CI build triggers deployment, and there's real-time alerts in production. When shit goes wrong, you should use the "five whys" to perform root cause analysis. Marty admits that this is only a good idea when there's a high-level of trust in your development team and lots of tests to prove nothing is broken.

The benefits of continuous deployment is there's a lower story cycle time, you eliminate waste in deploying code, you deliver features/bugs fixes faster and you find integration issues quicker and in isolation. It's also a great way to promote not checking in shitty code.

The skeptics think this is a bad idea because 1) it's scary, 2) they believe it causes lower quality and 3) it causes more issues in production. The good news is you can still control production deployments with your source control system (e.g. branches and such). More than anything, it forces you to have a high quality continuous integration system that acts as the gatekeeper for what goes to production.

You can learn more about topics Marty covered in this talk at the following sites:

• Eric Ries - http://www.startuplessonslearned.com
• Steve Blank - The Four Steps to the Epiphany
• Mary Poppendieck - Lean Software Development
• Dave McClure - http://davemcclure.com
• Kanban Applied to Software Development: from Agile to Lean

If you're lucky enough to be attending Aloha on Rails, Marty will be presenting there. I recommend you attend his talk if you're trying to get stuff done quickly and get it into production even quicker. His techniques seem to be invaluable for developers that are trying to maximize their efficiency and reduce the time it takes to get their code into production.

Building GWT Applications with MVP and Issues with Overlay Types

MVP has recently become a popular strategy for structuring GWT applications. This is largely due to its testability and Ray Ryan's Best Practices For Architecting Your GWT App from this year's Google I/O. GWT, by itself, is simply a widget toolkit and doesn't ship with any sort of MVC (or MVP) framework.

On my current project, we're using GXT, a GWT implementation based on ExtJS. It has its own MVC framework, but it has very little documentation and can be confusing when using it with GWT's History management. At one point, I attempted to make it more understandable by writing a blog entry on GXT's MVC Framework.

One of my initial assignments was to decide if we should use MVP or MVC. Regardless of which one was chosen, I was also tasked with deciding if we should use an existing framework or write our own. After watching Ray Ryan's session on YouTube and recalling my frustration with GXT MVC on my last project, I quickly became convinced MVP was the answer.

To test my "MVP is best for our project" theory, I did a spike to implement it. I used the GWT MVP Example tutorial as a starting point and added the following libraries to my project.

• GWT-Presenter: An implementation of the MVP pattern.
• Google Gin: Dependency Injection based on Google's Guice.
• GWT-Log: A log4j-style logger for GWT.

Implementing the MVP pattern itself was relatively straightforward, but I did encounter a few issues. I'm writing this post to see if anyone has solved these issues.

MVP Implementation Issues
The first issue I ran across was GXT's widgets don't implement standard GWT interfaces. To try and figure out a solution, I posted the following on Twitter:

"Wondering if it's possible to do MVP with GXT since it's buttons don't implement standard GWT interfaces."

The best response I received was from Simon Stewart (founder of the WebDriver project, works for Google):

"Put the GXT buttons in the View. Let that turn DOM events into semantic events."

He also pointed me to his tdd-gwt-gae project which shows many techniques for unit testing (with jMock) and integration testing (with GWTTestCase). Using Simon's examples, I was able to determine an initial strategy for implementing MVP with GXT.

My strategy is instead of getting widgets from the view and adding handlers, you add handlers to to the view and it takes care of adding them to the widgets that should listen for them. This seems to work, but my View interface has a lot of void methods, which is a bit different than standard MVP patterns I've seen.

The 2nd issue I encountered is with unit testing. Unit testing can be be performed on MVP applications by mocking out any dependencies that use JSNI. Classes that use JSNI are not testable with plain ol' JUnit and typically requires you to use GWTTestCase, which can be slow and cumbersome. This isn't to say that GWTTestCase isn't useful, just that it has its place.

When unit testing MVP applications, the recommended practice seems to be you should test presenters and not views. Services fall into a similar "don't unit test" category because they'll need to connect to the server-side, which won't be running in a unit testing environment.

This is where I ran into a major issue that I don't have a solution for.

I'm using Overlay Types (as described in JSON Parsing with JavaScript Overlay Types) to do JSON parsing in callbacks. Since Overlay Types use JSNI, it's not possible to do any JSON parsing in unit tests. The problem with not being able to do any JSON parsing is the callbacks will often call eventBus.fireEvent(GwtEvent) after the JSON parsing has happened. This means I can't fully test the flow of a presenter if event firing happens in a callback.

In attempt to try different mocking techniques for callbacks, I created a test that uses two recommended EasyMock-ing strategies. The first is a "CallbackSuccessMatcher" and is described in more detail in Testing GWT without GwtTestCase. The second technique uses a "CallbackMockSupport" class to allow EasyMock expectations such as expectLastCallAsync() and expectLastCallAsyncSuccess(T). You can read more about this technique in Test driven development for GWT UI code with asynchronous RPC.

Both of these examples use RPC, which typically has callbacks that have an onSuccess(T type) method. It's easy to use these callbacks in unit tests since T is a POJO and the onSuccess() method contains no JSNI code.

Currently, I see a few possible solutions to this problem:

• Figure out a way to detect when unit tests are running and add if/else logic to callbacks.
• Modify presenters and services so a callback can be set that is unit test-friendly.
• Make JSOModel an interface that can be replaced/mocked in tests.

The last solution seems like best one, but I'm also curious to know what others are doing. My hunch is that most GWT apps use RPC and haven't run into this issue.

Concurrency on the JVM Using Scala with Venkat Subramaniam

This evening, I attending the Denver JUG where Venkat Subramaniam was speaking about Scala. Unfortunately, I arrived halfway through his Programming Scala talk and didn't get a chance to learn as much as I wanted to. What I did see made Scala look very powerful and (possibly) easier to learn than Java. Below are my notes from Venkat's talk.

Concurrency is important these days because we're in a world of multiple processors. When you have multiple threads running at one time, it can become painful. Before Java, you had to learn the API for multi-threading for each different platform. With Java's "Write once, debug everywhere", you only had to learn one API. Unfortunately, it's pretty low level: how to start a thread, manage it, stop it, etc. You also have to remember where to put synchronize in your code.

With Scala, immutability and its Actors make it easy to program concurrent systems. For example, here's a web service that retrieves stock prices in sequential order:

def getyearEndClosing(symbol : String, year : Int) = {
  val url = "http://ichart.finance.yahoo.com/table.csv?s=" + 
    symbol + "&a=11&b=01&c" + year + "&d=11&e=31&f=" + year + "&g=m"
  val data = io.Source.fromURL(url).mkString
  val price = data.split("\n")(1).split(",")(4).toDouble
  Thread.sleep(1000); // slow down internet
  (symbol, price)
}

val symbols = List("APPL", "GOOG", "IBM", "JAVA", "MSFT")

val start = System.nanoTime

val top = (("", 0.0) /: symbols) { (topStock, symbol) => 
  val (sym, price) = getYearEndClosing(symbol, 2008)

  if (topStock._2 < price) (sym, price) else topStock
}

val end = System.nanoTime

println("Top stock is " + top._1 + " with price " + top._2)
println("Time taken " + (end - start)/10000000000.0)

To make this concurrent, we create Actors. Actors are nothing but Threads with a built-in message queue. Actors allow spawning separate threads to retrieve each stock price. Instead of doing:

symbols.foreach { symbol => 
  getYearEndClosing(symbol, 2008)
}

You can add actors:

val caller = self

symbols.foreach { symbol => 
  actor { caller ! getYearEndClosing(symbol, 2008) }
}

Then remove val (sym, price) = getYearEndClosing(symbol, 2008) and replace it with:

  receive {
    case(sym: String, price: Double) =>
      if (topStock._2 < price) (sym, price) else topStock
  }

After making this change, the time to execute the code dropped from ~7 seconds to ~2 seconds. Also, since nothing is mutable in this code, you don't have to worry about concurrency issues.

With Scala, you don't suffer the multiple-inheritance issues you do in Java. Instead you can use Traits to do mixins. For example:

import scala.actors._
import Actor._

class MyActor extends Actor {
  def act() {
    for(i <- 1 to 3) {
    receive {
      case msg => println("Got " + msg)
    }
  }
}

When extending Actor, you have to call MyActor.start to start the Actor. Writing actors this way is not recommended (not sure why, guessing because you have to manually start them).

Venkat is now showing an example that counts prime numbers and he's showing us how it pegs the CPU when counting how many exist between 1 and 1 million (78,499). After adding actor and receive logic, he shows how his Activity Monitor shows 185% CPU usage, indicating that both cores are being used.

What happens when one of the threads crashes and burns? The receive will wait forever. Because of this, using receive is a bad idea. It's much better to use receiveWithin(millis) to set a timeout. Then you can catch the timeout in the receiveWithin block using:

case TIMEOUT => println("Uh oh, timed out")

A more efficient way to use actors is using react instead of receive. With react, threads leave after putting the message on the queue and new threads are started to execute the block when the message is "reacted" to. One thing to remember with react is any code after the react block will never be executed. Just like receiveWithin(millis), you can use reactWithin(millis) to set a timeout.

The major thing I noticed between receive and react is Venkat often had to change the method logic to use react. To solve this, you can use loop (or better yet, loopWhile(condition)) to allow accessing the data outside the react block. In conclusion, reactWithin(millis) is best to use, unless you need to execute code after the react block.

Conclusion
This was a great talk by Venkat. He used TextMate the entire time to author and execute all his Scala examples. Better yet, he never used any sort of presentation. All he had was a "todo" list with topics (that he checked off as he progressed) and a sample.scala file.

Personally, I don't plan on using Scala in the near future, but that's mostly because I'm doing UI development and GWT and JavaScript are my favorite languages for that. On the server-side, I can see how it reduces the amount of Java you need to write (the compiler works for you instead of you working for the compiler). However, my impression is its sweet spot is when you need to easily author an efficient concurrent system.

If you're looking to learn Scala, I've heard Scala by Example (PDF) is a great getting-started resource. From there, I believe Programming in Scala and Venkat's Programming Scala are great books.

Labor Day Weekend at The Farm

This past weekend, the kids and I journeyed into the Colorado mountains for a weekend of camping, hiking and fishing. It was my good friend Matt Good's 50th Birthday Celebration at his place affectionately known as The Farm. We had beautiful weather, wide open spaces and lots of laughs with good friends. Jack even managed to land a girlfriend (Amanda), who somehow became his "ex" in the same hot tubbing session. They got back together the next morning.

On the way home, we took the long way and traveled from Ute Pass Road to Frasier, stopping at Lake Evelyn Trail for an hour hike and some fishing. I even let the kids drive a few times on the "bumpy road" and we managed to skip most of the traffic on the freeway.

More than anything, I was impressed with Abbie and Jack's ambition on this trip. They really seem to love hiking and fishing and don't drag their feet like they used to. They're also enthusiastic about camping and sleeping in a tent. I'm awful proud of my little munchkins. Below are some pictures from our weekend.

Thanks to Matt and Pam for hosting us and congrats to Matt on officially becoming an "old man". For more pictures, please see my Labor Day 2009 set on Flickr.