Just a Reminder to do TDD

I just pasted this onto my keyboard to remind me when I'm tempted.

Pictures from the Overview of Kanban - Austin SPIN Oct 11, 2012

David Hawkes CEO of Agile Velocity gave an overview of some Kanban concepts to the Austin Software Process Improvement Network

Here's the notes I jotted down during his talk:

Multitasking is bad
Why do we work on too many projects at one time?
- Not focused on deliverying value
- Maximizine utilization
- stakeholders need to have their project "In progress"

getKanban.com

Little's Law

Work In Progress
----------------   = Aggregate cycle Time
Throughput           

Stop Starting and start finishing

If we focus on fewer items at a time we can:
1. Increase productivitiy and deliver more
2. Get our customers more engaged
3. Have agility to adjust when changes occur
4. Lower our cycles times, less time to finish after getting a project
5. Limit the costs of delay

David Anderson wrote a Kanban Book for software development 2010

How to limit WIP
Throttling the input (demand) into the system

Lowering the WIP highlights the bottlenecks

Prioritization is no longer about ordering all the work, 
  but picking the next one

We need to optimize the whole system not just one part.

Kanban
Start with what you do now
Agree to continuous improvement
Respect the current process, roles, responsibilities
Encourage acts of leadership at all levels 

5 Core Properties of Kanban
1. Visualize Workflow
2. Limit WIP
3. Measure Meausre and Manage Flow
4. Make Process Policies Explicit - document what done means
5. Improve Collaboratively (Using Models/ Scientific Method)


Throttle demand to meet throughput in order to gain leveled flow

Shortening cycles and increasing the rate of delivery will build trust

Identify the constraint in your system and focus on optimizing the whole

Kanban companies here in Austin:  BankVue, HomeAway, BaazarVoice
Dan Pink RSA Drive video

Sprint time is how long you can resist change

64% of features are never or rarely used

Do we ever measure the usage of the features we delivery?

David Anderson in Austin - "Driving a Kaizen Culture Using Regular Operations Reviews"

David Anderson on March 17, 2011 spoke to a joint meeting of Austin SPIN, Lean Software Austin, IEEE CS Austin, and Agile Austin about a missing component of Kaizen culture, the Operations Review - what can your department do, how much of it did you do, and are you any good at it.
(I thought it appropriate since he espouses lean methodologies that he was wearing skinny jeans.)



Now this picture is not creepy because the girl in the cartoon is hugging David.

The Agile-Lean-CS-Spinners:

The main benefit of the standup meetings at a job was the after-meetings that allowed small teams of people, instant quality circles, to discuss and solve problems. This also struck me as a real benefit of this meeting - a chance to catch up with long-lost tech friends in the Austin community.

My random jottings:
Since academic software is seasonal, they share "Classes of Service" with car racing.
At the StandUp meeting only manage exceptions.
Many organizations only have a shallow implementation of Lean.
Real Kaizen is people just doing their jobs.

The meeting was a success - thanks to John Heintz for buying meals for everyone.

Unit Test Presentation

[This is the outline of a presentation I gave recently at our company on unit testing. Permanent link is here.]

What is Unit Testing?

Take the smallest reasonable piece of code, isolate it from the rest of the application, and programatically query it to ensure the results are what is expected.

1. Bad Things about Unit Testing:
   1. Unit Tests are expensive to write and very expensive to maintain.
      
   2. You can test too much.
      
      
      
      
      
      (Vertical axis is return on investment)
      
   3. You can test the wrong things.
      
   4. You can easily develop a false sense of security when all your unit tests pass.
      
   5. Having 100% code coverage doesn't mean your application is error-free.
      
      
      .
      
   6. When all your unit tests pass, it doesn't mean your application is error-free.
      
      
      .
      
   7. When all your unit tests pass, it doesn't mean your application is error-free. [sic]
      
   
   
2. Why Do Unit Testing?
   
   
   
   1. Encourages better software design - less coupling, smaller, simpler methods
      

      Instead of tightly interlocked code like this:

      
      
      
      
      
      
      

      Unit testing encourages code more like this, easy little blocks that can be replaced easily:

      
      
      
      
   2. Allows you to make deep changes in the software later with confidence
      
   3. Produces better quality software
      
   4. Gives you a framework for performance testing
      
   5. Finds errors in single components early, instead of finding multiple errors in multiple components which is exponentially more difficult.
      
   6. Easier to catch threading issues in unit tests
      
   7. The tests themselves are documentation
      
   8. It's more fun - really.
      
   
   
   
   
3. The Process of Unit Testing
   
   
   
   1. Write the test before creating any logic in your target method
      
   2. The first run of the test should prove it fails
      
      
      
   3. Write the simplest code in the target method to pass the test
      
      
      
   4. Refactor as needed.
      
   5. Repeat
      
   6. Red, Green, Refactor
      
   
   
   
   
4. Notes Unit Testing
   
   
   
   1. Don't confuse Unit Tests with integration tests or system tests.
      
   2. Unit tests should be independent of each other.
      
   3. Unit tests should not typically hit external entities like a database. The test should use a mock instead. This requires external object access to be done through an interface, not a concrete class. This improves your design.
      
   4. Unit tests do not obviate the need for human testing of the system
      
   5. Unit tests allow you to throw exceptions easily in code. It's hard to simulate some network faults, but with a mock object it's easy.
      
   6. Many Unit test frameworks are available. We use NUnit.
      
   7. Unit Testing is critical to Agile software development.
      
   8. Where to put unit tests? In the object itself? In same assemble? In other assemble?
      
   9. Unit tests should be fast, less than a minute. To make them faster, move integration tests to separate suite, don't talk to the database, skip some on your local test box my using categories, and only run those on the build server, e.g., CruiseControl.Net.
      
   10. Each unit test should create it's own data, and delete it when it's finished. Integration tests should start with a clean database, add needed schema and data, then end with a clean database.
       
   11. When you find a bug, write a test that exposes that bug, and make sure it fails. Fix the bug, then run the test.
       
   
   
   
   
5. Interesting Attributes in NUnit:
   
   
   
   1. [TestFixture]
      
   2. [Test]
      
   3. [ExpectedException]
      
   4. [Ignore]
      
   5. [Explicit]
      
   
   
   
   
6. Our Dojo exercise:
   

   Build a case-insensitive ordered string set class. We will implement, Add(string), Count(), Contains(string), Remove(string), and GetEnumerator()

   
   

   
   using System;
   using System.Collections.Generic;
   using System.Linq;
   using System.Reflection;
   using System.Text;
   using NUnit.Framework;
   
   namespace Utilities {
       // Case Insensitive Ordered String Set class
       public class CiosSet {
           public CiosSet()
           {
           }
   
           public void Add(string mystring)
           {
               
           }
   
           public int Count()
           {
               return 0;
           }
       }
       [TestFixture]
       public class CiosSetTest
       {
            [Test]
           public void Should_add_a_string_and_get_count_of_one() {
               Console.WriteLine(MethodBase.GetCurrentMethod());
               //Arrange
                var set = new CiosSet();
                //Act
                set.Add("abc");
               //Assert
                Assert.IsTrue(set.Count() == 1);
           }
       }
   
   }