Saw this movie in an IMAX.  Can you say awesome experience?!

I am sure a hundred people have said this before, but Heath Ledger’s performance was incredible.  He completely stole the movie from Christian Bale.  I totally believed the Joker was bat-@#%t crazy and I love the scene of him the hospital wearing the nurse’s uniform.  Totatlly over-the-top!

…and no one will volunteer, ask all the participants to stand up in a circle and assign one person at random to raise their right hand, reach into the center of the table to take the marker\pen\whatever and hand it to the person next to them!  It fakes them out every time!

“Test-driven development [TDD] is dual-entry bookkeeping to prevent errors in your code.”

I was lucky enough to see Uncle Bob give a presentation on TDD this week.  During his demonstration of the Bowling Game, I noticed he refrained from writing tests for the all the little helper methods he extracted during the course of the test-code-refactor cycle.  In the past, I had a tendency to take these private methods, make them public and write tests against them.  Something never felt right doing it, but it never hurts to have more tests, right?

However, after watching Uncle Bob, I understand why you don’t need to do that: the original method that spawned all the little helper methods is already well-tested.  If there was a defect in the private helper method, the public method will inform you.  Intuitively, I knew that and was beginning to go there.  Uncle Bob just moved that process along faster, so thanks!

In Boston, I attended a session lead by Neal Ford from Thoughtworks.  He shared his company’s experience of applying XP in a variety of domains.  Thoughtworks almost exclusively uses XP on all their consulting engagements.  Here are some thoughts on three pieces of misinformation about the XP community.

Pair Programming

Pair programming continues to remain controversial, but removing it from XP cripples the process.  The main reason is because eliminating pair programming takes away one of the key feedback loops XP is built upon – review of code by a second pair of eyes as it is written.  Having developers pair program increases the concentration, focus and productivity of the team.  I know it is counter-intuitive, but pair programming is one of the main reasons why XP teams make such great improvements in productivity.  Everyone is focused either with the writing code or thinking about how to improve the design.  No one is off surfing the net, killing time on the phone or responding to email – they’re working and working hard!

Kent Beck has clarified his position on pair programming in Extreme Programming Explained (2nd Edition) - not even Kent pair programs all the time! – and it remains very important to the process.  I feel pair programming is so tightly coupled to the identity of XP, that I would find it hard to believe a team is “really” doing XP (as if that really matters to anyone but us process nerds) if they are not pair programming.   IME, if a team says they are not doing pair programming and you dig into the details why, you normally find out they are not working in timeboxed iterations, not refactoring, don’t refactor and on-and-on.  The just took their ad hoc, undisciplined process and labeled it XP.

Documentation

Contrary to what people think they know about XP, good XP teams document their work.  They just tend to use light-weight documents for communicating to themselves, only preserve documents that are useful and avoid the “write-only” (think about it) documents often mandated by process police.  XP teams tend to use a wiki as a living document repository and their unit tests as a specification document built from code examples.   The wiki (probably one of the more revolutionary pieces of software ever created by XP’s “grandfather” and “midwife”, Ward Cunningham) is the place to hold user stories and the details surrounding the stories, preserve design discussions, design briefs and useful design diagrams and a place to maintain strategic and tactical decisions made.  I have seen Confluence be used very well when I worked at a large government contractor, but like anything else in XP, you need to be disciplined about maintaining it.

Code Comments

Code comments are a special form of documentation and are commonly thought of as a “best practice”.  Yes, we want to write comments about why we do something or capture the domain rules, but we do NOT want to write a comment telling me what the code does.  IME, if you need to write a comment in your code, then you have failed to express yourself clearly in your code.  Class, method and variable names all should be easy-to-understand and expressive.  When you read code, it should read like a blog entry, i.e. be coherent and comprehensible.  Document and comment your API, but writing JavaDoc style comments for code that will never been seen by the outside world only gets in the way of refactoring the code later.

… and the time for guerrilla Agile is over.”

Or so says Gil Borza from Industrial Logic at his talk at SD Best Practices titled “Secrets of High-Performance Agile Implementations”.  Gil’s position is Agile has proven itself in enough places and on enough projects that we should not hide the fact we are doing Agile anymore and just do it.  If you can’t do it, then change your organization.

One of the interesting refrains I heard regarding Agile transitions was the need for executive-sponsored Agile transitions teams with charters, budgets and authority to remove organizational impediments.  It was clear from many of the consultants that organizations who are successful with Agile transitions are the companies who put real money behind these initiatives, run transitions as change management programs using traditional project management tools and invest real money into their staff in the form of training and reduced productivity as the organization learns new skills and behaviors.  Real goals and milestones on what the organization should look like in 6-12-18 months are established and people are held accountable for their progress.  Giving everyone a copy of Kent Beck’s Extreme Programming Explained or Ken Schwaber’s Agile Project Management with Scrum and saying, “OK, now you are trained.  Go do it.” ain’t gonna cut it.

As for the practical side of things, rarely does a mismash of cherry-picked Agile practices work.  Eventually whatever you left out – pair programming, automated testing, lightweight documentation, cross-functional teams, stand-ups, etc. – will come back to haunt you later and kill your productivity.  It is very important in the early stages of the transition process to select teams and projects that are appropriate for the Agile approach.  When you are fixing bugs, there is just not that much to learn about how to be good at Agile.  If you think a team trashing around with legacy issues as there first Agile project will be a success, you are deluding yourself.    Once you have got over that big hump of learning, then you can extend Agile to parts of your organization that are tightly coupled to each other and perhaps tackle those nasty legacy bugbears using a SWAT team of your best technical and business folks.  Another thing to keep in mind, co-locate your teams\product communities as much as possible and don’t break up the communities.  Keep people together with the product.  A lot of time and money was spent investing in these growing and nurturing these communities (I like to think of them as corporate assets) and reallocating “the resources” when a project is done just pours all that money down the drain.

If you are serious about an Agile transition, recognize that every part of the organization that touches software development will have some type of change.  An Agile transition is trying to incrementally change the habitat in which an Agile team resides and to do that you need executive sponsorship.  Oh, if you lose your sponsor, you’re done (until you can find a new one).  Finally, expect to wait about a year before you start realizing the high productivity levels promised by Agile processes.

Here are some common mistakes people make when trying to make their organization more Agile from Rick Brenner and Nancy Van Schooenderwoert.  My comments are in italics.

• Underestimate the politics of the organization.  Avoid this trap at your peril.  As Ken Schwaber likes to say, “A dead sheepdog is no use to the team.”
• Use an Agile process to run the Agile transition.  Use tried and true change management techniques from the project management world.
• Allow the internal auditors to credential the Agile process.  Frequently internal auditors do not know what they are dealing with when confronted with an Agile project.  My experience is they often gum up the works to make their lives easier.  While these people are normally trouble, learn what they need.
  
• Scale up rapidly after a few successful pilot projects.  I call this early institutionalization or freezing the transformation process in an immature state.  You would never eat a green strawberry, so why push an immature system to your entire company?  Learn why the pilots are successful and amplify those factors while diminishing the obstacles.
  
• The early pilot projects are not run like projects; there are no goals, budget or customers.
• The “wrong” project was selected for the Agile team; i.e. legacy systems, unavailable customers, ill-defined goals, etc.  Agile teams need to work iteratively in close collaboration with a customer who cares about the project and has the authority to make decisions.  Anything less causes “issues”.
• Select team members who are actively hostile to Agile. Agile relies on the goodwill of the participants to try new things in order to succeed.Skepticism is good, but too much makes the whole thing a farce.
  
• Treat people as interchangeable resources and swap in-and-out at will. Agile asks people to make commitments by encouraging them to take ownership of products.  How much ownership do you really have when you are on four different teams?

Stopped by to listen to Larry Constantine today to hear what he is thinking about how to best design applications.  These are a number of the key points I picked up from his talk:

• Prioritize design efforts around tasks which have the most frequency and greatest importance.
• Organize designs around the fewest number of transitions for key tasks
• Keep the screen context consistent when you do transition.
• Use proximal and visual context to group related and associated elements.
• Provide context when offering corrections and support editing-in-place when the user makes an error.
• Edit-in-place is the best way to train the user on the correct data entry.
• Redundancy or alternate paths are in general a good thing; allowing actions to be reversible is better.
• For user tasks that are not reversible we need to carefully consider their design. (ed. duh!)
• Filter non-numeric characters from number only fields.
• Don’t make the user a subroutine of the program, automatically update known information if the user gave it to you.
• If there is a natural\alternative way of entering data in the real world, the machine should be flexible enough to accept it.
• If the error is obvious and detectable by the program, why tell the user about it?
• Propagate errors, and their cause, to the highest level that can handle them.
• If there is an error in the program, tell people where the error is and how to fix it.
• Don’t ever give an nodal\dialogue\confirmation box to a user unless the message is relevant, recognizable AND the user can intelligently respond to the message; otherwise just “eat” the message.

One of the sessions I visited today was about what are the correct measurements to determine if your SOA initiative was successful.  One of the most interesting statistic from the speaker was this continuum of cyclometric complexity (CC):

    CC < 10: "simple" code
    10 > CC < 20: "moderately" complex code
    20 > CC < 50: "severely" complex code
    CC > 50: "untestable"

He based that experience on a simple equation of:

    # of test cases = 2CC-1

Which suggests code with a CC as low as 15 will have 16,384 test cases!  Ouch!  That has got to hurt considering functional testing only gets you about 20% of test coverage.

I think another valuable observation provided was software reliability is inversely related to CC, the higher the CC, the less reliable the software.  The most eye-popping statistic from the talk was the speaker’s observation that if you can refactor your code to have a CC in the 10-15 range, an organization would reduce their maintenance costs by 2 to 5 times!

Finally, these are the ten measures from the talk that I thought I would share with all of you and how one should optimize the measures.  The words in the parenthesis are what level the measures speak to.

1. Dollars per service -> higher is better (corporate)
2. Service vitality index (new service revenue/total revenue) -> ~10%-20% is good (corporate)
3. Number of new services/total services -> higher % is better(management)
4. Mean time to service deployment -> lower t is better (management)
5. Mean time to service charge -> lower t is better (management)
6. Service availability -> higher % is better (management)
7. Service reuse -> higher % is better (project)
8. Cost of not using/stopping the service -> lower $ is better (project)
9. Service complexity -> lower CC is better (service)
10. Service QA confidence -> higher % is better (service)

…you cannot have collaboration.

My first stop at the SD Best Practices 2008 was a tutorial called “Collaboration Works!” by Ellen Gottesdiener.  I am familiar with many collaboration techniques, but I was looking for some additional tools and tricks (which I will include as separate posts later) and maybe sometime insight on some tricky issues from work.   Ellen asked everyone what their personal goal for the workshop was and mine was: “learn how to foster commitment in an environment of jaded people” (which might speak more to the goal owner than the actual people he works with).

I have spent a lot of effort lately trying to help people act more collaboratively, but they often hold back and are tentative.  True collaboration is elusive.  It seems as if there is often something (or someone) else “in the room” acting as an obstacle to collaboration.  Maybe it is me – ya never know, so I asked Ellen what she might identify as the problem.  Her answer was that a prerequisite for collaboration is trust.  That if there is no trust among the team member and\or between the team and management, there will be no collaboration.

Duh!  Trust - you have to have trust first! The issue had been staring me in the face for a long time, but Ellen finally gave me a word for it -trust.

We had a further dialgoue trying to dig deeper on how to overcome this obstacles.  She suggested that one needs to build safety within the team first before they have the capacity to share with management.   If the team did not feel safe with each other, they will not give management their candid opinions.  Her recommendation was to use visioning, chartering and retrospectives as tools to bring feedback to management that the team has issues around trust.  She also mentioned that incongruent behavior from management, i.e. “no overtime, but stay late to get it done”, will also further erode trust.

I will be heading for a great conference for the next few days, Oct 27th to Oct 30th, and will write up some short posts on what I saw and heard that was interesting and\or new.  I found this conference focuses less on technologies and more on techniques that work.  There will be a lot of sessions on Agile and many of the Agile thoughtleaders will be there.  Also, it does it hurt that this conference is in Boston.