Wednesday, February 19, 2014

Six Techniques for an Effective Retrospective


If a non-agile team were to adopt one single agile technique, what would it be?

My answer, without a doubt, is a regular retrospective.  Why?  An effective retrospective allows you to continually improve your process.  It allows you to add in the other Agile techniques, gradually, as your team is ready for them.  Over time it can be the gateway to a fully agile process that is completely customized for your team.



But there is a fine line between an effective retrospective, and a gripe session that that fails to lead to process improvement.  These six techniques can help you get the most out of your retrospectives.

1. Prepare items before-hand


One of the most important steps for an effective meeting is to have a clear agenda.  Asking team-members to prepare retrospective items ahead of time lays an specific agenda which facilitates:

  • Allocating an appropriate amount of discussion time per item
  • Producing more well thought out, higher quality suggestions
  • Knowing when the meeting is over

2. Centralize items in a repository


Specifying a central location such as a Google Docs spreadsheet or a SharePoint list that team-members can add to as items occur to them can further increase meeting effectiveness.  Not only can team members see and prepare to respond to other team members, but it represents a history of changes, and can provide more structure in entering items.

3. Identify problems and solutions


Unstructured retrospective items submitted by team members seem to come in one of two forms:

  1. Solutions in want of a problem; and 
  2. Problems without a clear solution 

Both types of submissions aren't necessarily bad, but they can lead to ineffective process changes or long discussions that fail to result in meaningful change.

The most effective retrospectives I've seen ask team members to present both a problem and a solution.  By separating off the two sides of the coin the group can decide as a team if there are perhaps better solutions that fit the problem.

4. Revisit old solutions


If a team member has identified a problem and the group has arrived at a process change, how can the team be sure that the solution fixed the problem?

The best approach is to have the team revisit old unresolved items at each retrospective.  If the solution solved the problem, resolve it.  If not, postpone for another meeting or propose another solution.

5. Focus on process, not individuals


Invariably person X will do something to upset person Y.  Then Y will want to bring the issue up at the retrospective.

Having a problem/solution format will help discourage airing personnel issues, but proactive leaders will want to establish some rules ahead of time to encourage team members to work out issues outside of the retrospective to keep the meeting focused on the team's process.

6. What went well


While no concrete changes typically comes from a "what went well" section of a meeting, a pat on the back never hurts, can keep morale up, and can encourage team members to keep doing the good parts.

Summary


With a little extra structure your retrospectives can be shorter, more results-oriented, and more effective.  Why not give these tips a try at your next retrospective?

And if you aren't doing retrospectives?  Schedule your first, you won't regret it.

Wednesday, November 13, 2013

24 Resharper Tips



I firmly believe ReSharper is the best thing to happen to .Net since Visual Studio (NCrunch is a close second).  In evangelizing it I managed to convince my program to purchase copies for every developer.  One caveat: I had to train everyone.

So next week I'm doing a ReSharper presentation.  To keep the talk interesting I thought it would be fun to incorporate a game of Bingo with ReSharper shortcuts.  Get five horizontal, vertical, or diagonal shortcuts when mentioned, yell BINGO, get a prize (Siren of Shame mug anyone? :) ).

Five tips times five tips minus a free spot = 24 tips.



So why not make a blog post while I'm at it?  I've been collecting my favorite tips for years now anyway.  So without further ado:

1. Navigate to Class (Ctrl+T)


Man I love this shortcut.  Need to get to the TrippleDesStringEncryptor quickly?  Ctrl+T then type the capital letters "TDSE" and enter.

2. Rename (Ctrl+R+R)


I use this so often it's become muscle memory and I nearly had to look it up.  It works differently in different contexts.  For local variables it works by renaming all usages inline.  For methods there's a quick modal dialog.  For classes there's a modal dialog that even allows you to synchronize the file name.

3. Move to Another File: (Alt+Enter)


This is fabulous when you're in quick-and-dirty problem solving mode, throw a new class in the same file, but want to fix it when you switch back to refactor mode. Just put the cursor on the class name and hit Alt+Enter+Enter.

4. Extract variable (Ctrl+R+V)


I use extract variable almost with the frequency of Rename.  When you switch back to refactor mode after an intense quick-and-dirty coding session extracting literals or variables is awesome.  For instance if you have:

if (!FileInputOutput.Exists(fileName))

You can select everything inside of the if statement, hit Ctrl+R, V, and ReSharper turns it into something lovely and self-documenting like:

var logFileExists = !FileInputOutput.Exists(fileName);
if (logFileExists)

5. Run Unit Tests (Ctrl+U+R)


I've switched to NCrunch for running tests, but if you aren't so lucky Ctrl+U, R is super handy for running all tests in the solution.

6. Rerun Unit Tests (Ctrl+U+U)


This test running alternative is fantastic for when you're working on a single unit test and need to keep running it as you make small changes.

7. Navigate To (F12/Ctrl-Click)


F12 to navigate into a method is nothing new.  ReSharper adds the ability to hold the control key and hyperlink into a method with a click of the mouse.  Even if you're a keyboard person (like me) this shortcut comes in handy from time to time.

8. Go Back (Ctrl+Minus)


Technically a Visual Studio shortcut, but it's so awesome I just had to list it.  I use it constantly if I've just navigated to a method to peek and I want to return back to where I was.

9. Find usages (Shift+F12)


Visual Studio has the ability to find usages of a method, but it pretty much sucks.  If a method is called only once, for instance, ReSharper goes right to the callee without popping up any dialogs.

10. Next/Prev Method (Alt+Up/Down)


I tend to navigate more with F12 and Shift+F12, but zipping down the methods a class comes in handy from time to time.

11. Delete line (Shift+Del)


Again a Visual Studio shortcut, but one I use constantly.  Yayy to deleting code!

12. Convert to LINQ (Alt+Enter)

So subtle, so mind-blowing.  Imagine you have this code:

foreach (var logFile in logFiles)
{
    if (!logFiles.Contains("Test"))
    {
        Console.WriteLine("Found prod file: " + logFile);
    }

}

If you place the cursor over the foreach statement ReSharper prompts you "Convert part of body into LINQ-expression".  And (with Ctrl+R V) like magic:

var prodLogs = logFiles.Where(logFile => !logFiles.Contains("Test"));
foreach (var logFile in prodLogs)
{
    Console.WriteLine("Found prod file: " + logFile);

}

Heck yea!  This refactoring works in a huge number of scenarios.  It boggles the mind how smart the folks at Jet Brains are to be able to convert procedural code into functional code like that.

13. Convert to Ternary (Alt+Enter)


I have mixed feelings on the ternary operator (e.g. "return hateTernary ? avoidIt : useIt").  These feelings closely mirror my mixed feelings on using multiple return statements from a method (use with caution).  To use it on something like this:

public string GetFilePrefix()
{
    if (Message.Contains("Test")) return "Test_";
    return "Prod_";

}

Put your mouse over the if statement, type Alt+Enter, Enter, combine in an Extract Variable and you get:

public string GetFilePrefix()
{
    var isTestLog = Message.Contains("Test");
    return isTestLog ? "Test_" : "Prod_";
}

Better, right?

14. Extract Method/ Property (Ctr+R+M)


Visual Studio has something similar, but ReShaper's shows you a little preview and you can uncheck parameters that you'd like to handle yourself.  I use this constantly.

15. Insert Code (Alt+Ins)


Useful for inserting constructors and overriding virtual methods.  Super-awesome for inserting extremely hard to get correct code like equality members (e.g. you always remember to override GetHashCode and the non-generic overrides and the == and != operators, right?).

16. Make Public/ Private (Alt+Enter)


This shortcut saves typing when you're on public/private/protected keyword, but little known fact: you can also use it on the other end when you're trying to call a method you don't yet have access to.

17. Extract Interface (Ctrl+Shift+R)


I'm not a big fan of interfaces for reasons I'll enumerate another time, but when you do need them the ability to turn a class into an Interface is really awesome.

18. Navigate to Implementation (Alt+End)


If you're living in code that uses a lot of interfaces you probably hate F12 because it takes you to the interface rather than the implementation.  ReSharper and Alt+End to the rescue.

19. Navigate to Base (Alt+Home)


Navigate to Base will take you to an Interface if you're in a base class.  It will also take you to the virtual or abstract method you're overriding if you're in a subclass.  Very handy.

20. Implement Members (Alt+Enter)


Will make you very happy when you need to override an abstract class or interface.  Just put the cursor over the base class or interface and hit Alt+Enter, Enter.

21. Next Warning (Alt+PageDown)


The static code analysis features of ReSharper are legendary.  If the tool finds a lot of issue in a given file you can jump through them quickly with Alt+Page Down or Alt+Page Up.

22. Change Signature (Ctrl+R+S)


How often have you wanted to move a parameter from the Nth position in a method to the first or last? If you're anal like me all the time.  Ctrl+R S saves the day.

23. Un/Comment (Ctrl+K, C or Ctrl+K, U)


Alright, another Visual Studio shortcut, but I'm always surprised at how few people know about this.  Ctrl+K and then C while selecting several lines of code will comment them out.  Ctrl+K and then U uncomments.

24. Surround With (Ctrl+E+U)


Such a nice shortcut for surrounding a block of code with an if statement, using block, or try-catch statement.

Summary

I hope you've found these 24 ReSharper tips useful.  What are your favorites?  Please post in the comments or start a conversation with me on twitter @lprichar.



11/17/13 Bonus Tips
After receiving some great additional tips on twitter and after watching the Resharper Fundamentals pluralsight course I thought I'd add the following three tips:

25. Duplicate Line (Ctrl+D)
Great tip from @g00fygrin, I use this all the time.

26. Locate in Solution Explorer (Shift+Alt+L)
As @therealbennor said this is great when you're jumping around a lot with Ctrl+T and F12. Personally I prefer the "Track Active Item in Solution Explorer" option under "Projects and Solutions", but I know that's not a popular feature.

27. Bookmarks (Ctrl+Shift+1 to set Ctrl+1 to go to)
I learned so much from the Resharper Fundamentals pluralsight course. I can't recommend it enough. This tip in particular made my day. Fantastic for large codebases.

Wednesday, October 23, 2013

Learning C# via Katas - Part 2 - Extension Methods

This is part 2 in a series of blog posts exploring CSharpKatas, a new GitHub project and training tool I put together.  The Katas teach C# newcommers how to apply advanced language features, how to write idiomatic C#, and most importantly how to avoid Java idioms.

If It Types Like a Duck


Kata #1 introduced the reader to LINQ and some replacements for loops and if statements.  Kata #2 focuses on a feature typically found in dynamic languages that allows adding methods to other people's classes without modifying or subtyping the class.  The feature, called extension methods, introduces to C# elements of a feature known as "duck typing" found in languages such as Ruby or JavaScript.

Duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface. The name of the concept refers to the duck test, attributed to James Whitcomb Riley, which may be phrased as follows:
When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck

Unlike with dynamic languages, however, C#'s extension methods are implemented via some fancy compiler trickery.  The details of the trickery is captured in the third todo in the Kata in which the reader is asked to reverse engineer the Intermediate Language (IL) code after compiling the solution.  This final todo will also add a powerful tool to the reader's toolbelt.

Caveats and Limitations


Due primarily to the compiler trickery mentioned above extension methods have drawbacks over what dynamic language aficionados would likely expect.  For instance isn't possible to add static methods onto other people's classes.  Additionally, one can't add properties to external classes.  This last limitation has frustrated me on more than one occasion.

Another limitation is that extension methods require both knowing the namespace an extension method is defined in, and adding a related using statement.  This limitation can make it hard for others to discover your extension methods.  It can also decrease readability as it can be difficult to determine where a method actually lives.

Finally a caveat: it can be easy to over use extension methods after first learning of them.  For instance just because you could add a SpellCheck() method onto C#'s String class, would you really want this in your code:

foreach (var error in "I'm a bad speller".SpellCheck())
{
    // The above is a bad idea, please don't do it
}

Kata #2


With the caveats and drawbacks out of the way here is a copy of the second Kata:

using System.Collections.Generic;
using NUnit.Framework;

namespace CSharpKatas
{
    // todo #1: Without modifying SomeoneElsesClass add a new class that 
    //     makes the unit tests pass
    // todo #2: Refactor so that there are no loops or if statements.
    // todo #3: (see below)


    #region DoNotModify
    // DO NOT MODIFY THIS CLASS
    public class SomeoneElsesClass
    {
        public List<int> Numbers { get; set; }
    }
    #endregion

    [TestFixture]
    public class TestExtensionMethods
    {
        [Test]
        public void FindNumberOrDefault_NumberExists_ReturnIt()
        {
            var someoneElsesClass = new SomeoneElsesClass
            {
                Numbers = new List<int> { 1, 2, 3 }
            };
            Assert.AreEqual(1, someoneElsesClass.FindNumberOrDefault(1));
        }

        [Test]
        public void FindNumberOrDefault_NumberDoesNotExist_ReturnNull()
        {
            var someoneElsesClass = new SomeoneElsesClass
            {
                Numbers = new List<int> { 1, 2, 3 }
            };
            var v = someoneElsesClass.FindNumberOrDefault(4);
            Assert.IsNull(v);
        }

        [Test]
        public void FindNumberOrDefault_SomeoneElsesClassIsNull_CheckForNull()
        {
            // todo #3: What's bizarre about the following test? Why is there 
            //    no error? Consider reverse engineering the code with a tool 
            //    like Just Decompile to get the answer.
            SomeoneElsesClass someoneElsesClass = null;
            Assert.IsNull(someoneElsesClass.FindNumberOrDefault(4));
        }
    }
}


Summary


I hope you find these Kata's fun and enlightening and that you find my enthusiasm for the C# language contagious.  Enjoy!  And feel free to ask questions in the comments here or @lprichar on twitter.

Wednesday, October 16, 2013

C# Isn't Java - Learning via Katas - Part 1

CSharpKatas is a new GitHub project and training tool I put together.  It teaches C# newcommers how to apply advanced language features, how to write idiomatic C#, and most importantly how to avoid Java idioms.


C# Isn't Java


C# is at least a decade ahead of Java, and that's being generous.  Sadly many junior, ex-Java, and even some seasoned C# developers continue to use Java idioms in C# and think of the two as equivalent.  I've overheard "C# is just like Java" more times than I care to recall, and it makes me angry every time.

If you too become frustrated hearing these similes and need a resource, or you find yourself on a C# project with Java coders, or you could just use a refresher on writing idiomatic C#, then CSharpKatas is for you and/or your team.  I hope you enjoy and that it becomes a valuable resource for you and the C# community.

Java is Blub


Why do people confuse Java with C# to begin with?  Partly this is Paul Graham's Blub Paradox at work:

Blub is a hypothetical programming language … As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

Java is Blub and C# the more powerful language.  C#'s power is derived from the huge array of language features it has that Java lacks (and that Java won't have for at least a decade if ever).  Some of these features include:


Those that equate C# and Java are likely unfamiliar with many of the features listed above.  Should they happen to run into code that, for example, uses a method missing catch-all (aka TryInvokeMember) they just see weird constructs and "hairy stuff" and assume incorrectly that C# is equivalent with Java.

C#'s Beauty Revealed


My lofty goal is first, to put a stop to the misconception that "C# is just like Java" and second, to encourage C# newcomers to write idiomatic C#.  To accomplish this I put together a set of Code Katas, or mind exercises that I published in a github project.

Each Kata consists of a set of failing unit tests and some to do's.  The problems are generally extracted from real problems I've had to solve and are designed to introduce new concepts gradually.  Developers are asked to turn the tests green using any means necessary, then refactor using C# idioms (such as not writing loops or if statements without good reason).  The exercises assume a solid working knowledge of an OO language such as Java and an ability to look stuff up in the documentation.

Perhaps along the way developers will become convinced of how wonderful TDD and Red-Green-Refactor is, but that's incidental.

Now if you're more of a book learner, or just want more depth, I would highly encourage you to read Jon Skeet's awesome book C# In Depth.

Or if, like me, you're more a hands-on learner I would encourage you to follow along at home by branching or pulling my CSharpKatas project and trying to solve the problems in your own branch.  If solving a Kata takes more than a few minutes I recommend you delete your solution and do it again until solving it is second-nature.

Finally, there are no solutions published.  If there is demand I may publish my solutions, but the "to do"'s should be sufficient.

Kata #1


The objectives of the first Kata:

  • Learn to run C# unit tests
  • Learn basic alternatives to loops and foreach statements
  • Learn how to use lambdas and some LINQ to Objects

Without further ado here is a copy of first Kata:

using NUnit.Framework;

namespace CSharpKatas
{
    public class Calculator
    {
        public int SumNumbers(int start, int count)
        {
            // todo #1: Get all the tests passing
            // todo #2: Refactor so there are no loops or if statements (this
            
//    is the functional approach and is idiomatic for C#)
            // todo #3: Refactor to use the Aggregate() LINQ method            
            //    see 101 Linq Samples)
            return 0;
        }
    }

    [TestFixture]
    [Ignore]
    public class Test
    {
        [Test]
        public void SumNumbers_StartAt100SumNext1_TotalIs100()
        {
            var kata = new Calculator();
            Assert.AreEqual(100, kata.SumNumbers(100, 1));
        }

        [Test]
        public void SumNumbers_StartAt100SumNext2_TotalIs201()
        {
            var kata = new Calculator();
            Assert.AreEqual(201, kata.SumNumbers(100, 2));
        }
        [Test]
        public void SumNumbers_StartAt100SumNext0_TotalIs0()
        {
            var kata = new Calculator();
            Assert.AreEqual(0, kata.SumNumbers(100, 0));
        }

        [Test]
        public void SumNumbers_StartAt0SumNext0_TotalIs0()
        {
            var kata = new Calculator();
            Assert.AreEqual(0, kata.SumNumbers(0, 0));
        }

        [Test]
        public void SumNumbers_StartAt0SumNext3_TotalIs3()
        {
            var kata = new Calculator();
            Assert.AreEqual(3, kata.SumNumbers(0, 3));
        }

        [Test]
        public void SumNumbers_StartAt0SumNext100_TotalIs5050()
        {
            var kata = new Calculator();
            Assert.AreEqual(5050, kata.SumNumbers(1, 100));
        }
    }
}


Conclusion


I hope you find these Kata's fun and enlightening and that you find my enthusiasm for the C# language contagious.  Enjoy!  And feel free to ask questions in the comments here or @lprichar on twitter.