Life, Liberty, and the Pursuit of Agility

The Agile Manifesto – Values and Principles are the foundation.

My Maxims are not meant to distract from or replace them.  My Maxims are just another way to for me to frame my thinking.

I spend a lot of time scrutinizing the things I value to make sure I can minimize my blind spots and unknowns, at least the ones that make the most difference. Seems I am usually my own worst enemy.

I share my Maxims so I can get feedback from you and learn where I can improve.  Please be kind.

Agile Open So Cal 2012 at UC Irvine.

Once again I have been able to participate in the Agile Open So Cal at UC Irvine.  Great fun, great people, great sessions, great etc.   Several people had seen me tweet these “Maxims” or heard me talk about them before, and asked me to present them again.  It takes VERY LITTLE URGING to get me to talk about Agile, Lean, Clean Code, or anything programming.  So, I proposed a session –  and here are the notes:

Title: The 8 Agile Maxims of Software Development

Byline: This time it’s personal.  With Woody, it’s always personal.

Here they be (in no particular order – you can mix and match):

1- It is in the doing of the work that we discover the work that we must do. Doing exposes reality.

I live this daily.  Thinking about stuff is obviously worthwhile – I don’t discount that. But doing is way more important.

2 – “Responding to Change” is impossible unless code is easy to change, easy to maintain, easy to fix, easy to enhance, easy to read, and easy to discard.

The “easy qualities” –  I learned them from the greatest programmer I have ever worked with: Fred Zuill, my little brother. Back in the 90’s he used to do a talk on the Qualities of Software that was pithy, meaningful, and wickedly sardonic.  If you ever get a chance to hear him speak, do it.  If you see him please remind him he owes me $18.

3 – Question Everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.

I’m pretty good at getting comfortable in my ways.  Gotta work at keeping that from blocking improvement.  When I really believe something, I’m likely to be fooling myself.  Lets keep things uncomfortably wonky.

4 – “Working Software” is software that users are actually using. Until it’s in use it is truly useless.

This is my understanding of how “Working Software” should be thought of (as in the Agile Value of “Working Software over Comprehensive Documentation”).

Let’s not fool ourselves: “Potentially Deliverable” is a lot like “The check is in the mail”.

5 – Stress at work diminishes value. Crunch-time is a symptom of harmful and counter-productive attitudes.

Nuff said?  I hope so.

6 – We are the innovators of our process. Learn what works for others, prove it for our self, innovate beyond.

Just a suggestion: Don’t wait until you are an “expert” to innovate.  Just like Jello, there is always room for innovation.  (You remember those ads for Jello, don’t you?  Dang, you young people really missed out on the best days of television. You remember television, don’t you? Dang… I’m getting old, so it seems)

7 – The object isn’t to make great software, it’s to be in that wonderful state which makes great software inevitable – Robert Henri, paraphrased

This is a paraphrase of the well known quote from Robert Henri.  Just replace “great software” with the word “art” and you get the original (and much more meaningful) quote.  I replay this one over and over in my head all the time.  Wish I was the one who had said it! I was introduced to this quote many years ago by Donald Faast, an amazing show-card writer and sign man. I think he is in Colorado now.  If you see him, just say thanks for me if you would.

8 – The more we work at the work we do, the less capable we become -Repenning/Sterman – Make time for improving capability

Dang.  If you haven’t already read the paper “Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement” by Repenning and Sterman then please click on it and read that now: http://bit.ly/Qd3NmR – It’s a pdf file.

9 – I reserve the right to add, remove, change, improve. (This one has been added since the session).

I expanded on these greatly during the session, and invited feedback, observations, and discussion.  Unfortunately I was not able to take notes.  Overall, I feel it was well accepted and if it was not, my memory has already painted it much better than it actually was.  Thank you memory!

Remaining Puzzles, Recommendations, Next Steps:

I pointed out that these Maxims will change and grow, and invited the participants to add, remove, change, improve

Also… A BIG thanks to Drew LeSueur – @drewlesueur – from Integrum Tech

Drew has been very encouraging to me, and on his own he quickly put up a site and posted the Agile Maxims: http://agilemaxims.org/ –   Remember, this whole thing is just me thinking out-loud.

[NOTE: To make sure people are paying attention, I always purposefully put a hidden typo in my posts… see if you can find it.]

Below are my 8 Agile Maxims.

They are not in any particular order, although my favorite is probably the paraphrase from Rober Henri.

You’ll note that there are now Nine… the ninth one simple is a disclaimer that this is bound to grow, shrink, or otherwise change over time.

• It is in the doing of the work that we discover the work that we must do. Doing exposes reality.
• “Responding to Change” is impossible unless code is easy to change, easy to maintain, easy to fix, and easy to enhance.
• Question Everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.
• “Working Software” is software that users are actually using. Until it’s in use it is truly useless.
• Stress at work diminishes value. Crunch-time is a symptom of harmful and counter-productive attitudes.
• We are the innovators of our process. Learn what works for others, prove it for our self, innovate beyond.
• The object isn’t to make great software, it’s to be in that wonderful state which makes great software inevitable – Henri
• The more we work at the work we do, the less capable we become -Repenning/Sterman – Make time for improving capability
• The unspoken Agile Maxim – I reserve the right to add, remove, change, improve.

I’ve had the great fortune lately to have a little extra “uncommitted” time to spend exploring things that I’m interested in.  On the top of my “to be explored” list is Approval Tests.  I’ve been using it a bit over the last few months, but haven’t had time (until now) to dig deeper.

Approval Tests is an open source project with the purpose of providing a very simple way to solve some difficult testing problems.  For example, one thing that Approval Tests makes easy is to provide characterization tests for legacy code.

I use characterization tests to lock down the existing behavior of code I need to work on – in other words, it is a test that proves the code does whatever it is currently doing so that I can refactor and clean it with confidence that I won’t accidentally change it’s behavior.

I first came upon the term in Michael Feathers amazing book (Working Effectively with Legacy Code), and have commonly used mock object frameworks to implement my characterization tests.  However, that can be a complicated and time consuming process, and can sometimes require some refactoring to modify the code so it can be tested.  Usually these are very safe refactorings – but can still introduce bugs.  Another issue is that coverage is typically very localized to the method of interest and perhaps a few depended-on objects.

Enter Approval Tests:  You get a lot of bang for the buck.  For example, in one of the presentations I do (Code Excellence for the Average Programmer) I show how a real life project that had become impossible to maintain or enhance was revived using very simple code-cleaning techniques.  It only took four unit test methods of a few lines each using Approval Tests to introduce sufficient code coverage to be able to confidently work on the project.

The essential concept of using Approval Testing this way is to allow the code you want to test to produce a result that you then capture by “Approving” it (which saves it).  This approved result will then be used when you run the test to verify the results.  Whenever anything changes, the test will fail and you’ll be shown the differences.  Sounds simple, doesn’t it?  And it is!!!  Approval testing has a number of other uses, and perhaps I’ll have a chance to write about those sometime soon.   I bet you can’t wait.

I encourage you to take a look the next time you get a chance: Approval Tests.   The Approval Tests project was invented by Llewellyn Falco and Dan Gilkerson, and they invite your suggestions and help on expanding and improving it.  Also, they have a talk they’ve been doing at various conferences and code camps.  If you get a chance to see it I am sure you’ll find it an eye-opener.  The next scheduled presentation is at the Silicon Valley Code Camp, and it’s called “Unit Testing the Easy Way”.   I’ll be helping out on that one since Dan can’t make it, and I’m really looking forward to that.

I’m signed up to do 3 talks at the upcoming UCSD SoCal Rock & Roll Code Camp in La Jolla.   The dates are June 28th and 29th at University of California San Diego Extension – you can get the details and maps, schedules, and etc. at the link above.

Agile Development Basics – In this presentation I cover the Agile values and principles, as well as the a little about why we need something like Agile.

A Quick Introduction to Scrum – Here I’ll present the who, what, and how of Scrum.  Scrum is one of the most common methodologies for managing an Agile effort.

Agile Coding Techniques for Legacy Apps – This talk shows various techniques for introducing unit tests and micro tests into an application that has insufficient tests.

I am planning on doing a couple of additional talks on using NMock or Mock Objects, and I’ll post the details here as soon as I get the time to sign up for the presentations.

It is always a great time at all of the Code Camps.  I’ve been to 4 or 5 in the last year, including the Fullerton and San Luis Obispo code camps – I highly recommend you attend if you possibly can!  Every Code Camp I have been able to attend has been a wonderful experience for me.   So far there are about 80 sessions, and there will probably be a few more added over the next week or two.

Jason and I had a great time presenting at the XPSD last night, and meeting up with the Ruby programmers later on at the Rock Bottom in La Jolla.

As far as I could tell it went over pretty nicely, and everyone really enjoyed watching Jason coding live on his laptop where the ReSharper demo license had just expired.  He didn’t let it stop him, and it was a nice demonstration of how pitiful life can be without a good refactoring tool. 

Here are the slides from the NMock2 intro presentation givn at XPSD.org on April 3rd.

NMock2_Intro.pdf

Don’t get your hopes up too much – they are just my talking points.  I hope you find them useful.

When I do my “Quick Introduction To Scrum” presentation  the most popular feature is a little Sprint task board animation that I put together in PowerPoint.  I got the idea from a slide from the ScrumMaster training that Ken Schwaber provides.  My main goal was to try to give a visual “time-spanning” representation of what a Sprint task board “looks and feels” like over a two week Sprint that is operating in a more or less healthy manner.    If you aren’t doing Scrum, but rather some other Agile methodology,  just replace “Sprint” with “Iteration”, and “Scrum” with “Agile” and you’ll do fine. 

I’ve converted the animation to Flash and added a little running  commentary to cover a few things about how we

Continue reading ‘The Task Board Animation’ »

Jason Kerney and I will be making a presentation on the basics of using NMock2 with C# at the San Diego Dot Net Developers Group tonight, Feb 5th, 2008.  The meeting starts as 6:00pm.  They have a new meeting place, so if you haven’t gotten the emails, please check the site for information and directions.  They are now meeting at the AMN buildling in the Del Mar Heights area.  Pizza and soda is being provided by the Eastridge Infotech staffing company.

This is essentially the same presentation from Code Camp, but slightly tuned and tightened up.  We had very good response for this presentation from the code camp crowd.   This talk is mostly code, with just a short introduction of slides to set the stage.

Hope to see you there. 

NMock2 Presentation at Code Camp

In addition to the other presentations I posted earlier (Speaking at SoCal Rock & Roll Code Camp) , I’ve added one more session for Code Camp.   Jason Kerney and I are pairing up to do a session on using dynamic mock objects with the NMock2 framework, which is something we’ve recently been using quite a bit.  The talk is titled “A Little Taste of NMock2 For That Smooth Unit-Testing Flavor”. 

Mock Objects are a great tool for testing the behavior of your system in a very focused manner. This presentation covers the NMock2 open source dynamic mock object library and shows how you can easily put it to work for you.  Continue reading ‘NMock2 Presentation at Code Camp’ »

A co-worker (Jason Kerney) and I have been messing around with NMock2 in C# for a while now, and we’ve put together an introductory presentation on the basics of using NMock2 that we are going to give at the upcoming Code Camp at Cal State Fullerton.  [January 25th & 26th, 2008 – Code Camp is a free conference put on by developers for developers].

This article is not our presentation, but rather a little introduction about using NMock2 for doing exploratations into existing code.

You are probably familiar with using assertions in NUnit tests.  Assertions reveal in what way the object and/or some other collaborating object has changed during an operation by cheking state, and are also used to verify the result returned from an operation. Mock objects, on the other hand, provide a way to test the behaviors of code. That is, mock objects test what the object is or isn’t doing.  Mock objects are often used together with assertions to better pin down the code under test. Continue reading ‘NMock2 as a code exploration tool’ »

I’m doing 3 talks – maybe more – at the SoCal Rock & Roll Code Camp this year January 27 & 28th, 2008, at the Cal State Fullerton Campus. 

Agile Development Basics  – In this presentation I cover the Agile values and principles, as well as the a little about why we need something like Agile.

A Quick Introduction to Scrum – Here I’ll present the who, what, and how of Scrum.  Scrum is one of the most common methodologies for managing an Agile effort.

Agile Coding Techniques for Legacy Apps – This talk shows various techniques for introducing unit tests and micro tests into an application that has insufficient tests. 

Last year the Code Camp was a lot of fun with a lot of great presentations and get-togethers with fellow developers.  I’m looking forward to seeing everyone again and learning a lot of new, useless stuff.